Discussion for revised fees

[virtual_master]

We could set up a second domain now. Then:
1.
For ex .new which should use more experimental fee model.
The .bit domain registration should remain more conservative.
When we introduce something new or additional in the fee system first should be used 1 year on the .new.
Then we will see if the new fee system brings more namecoin movement in the network. If yes it could be applied to the .bit domain also.
2.
Other option could be if the fees for .bit domains would be higher and for .new lower.
For ex
10.000 .bit registrations x 0.1 namecoin fee = 1.000 namecoins.
50.000 .new registrations x 0.01 namecoin fee = 500 namecoins.
The higher wins.
Of course this could be dependent from the namecoin price also which one has more success.

This could be used for other experimentation's also.
For ex. one domain could have flat fees the other dependent on the length of the name.

I think the registration length is not so critical because you could renew your domain any time as far as I know for 1 year.
So if you go for 2 months in holiday you renew it. ( but you loose 2 months of fee, which is not so tragical)

[domob]

My opinion is that the current order of magnitude of costs as well as expiration time is quite good. IMHO, it is a feature that NMC names are much cheaper than official domain names. I can / will register a namecoin domain any time for even smaller projects of mine, while I've so far only registered official domain names for my actual website (domob.eu and daniel-kraft.net) but never even thought about doing so also for smaller projects of mine (which are instead located within my domob.eu page).

However, I think the idea to make fees depend on the name length (at least to some extend) seems a good one to me. What about also making them dependant on the namespace - d/ could be more expensive than id/, for instance. Non-standard namespaces and names like "foobar" without namespace could be even cheaper. (One could even think about dynamically determining the charged fee depending on how many names there currently are in the namespace in question, so that this has not to be hardcoded and can adapt to new namespaces.)

I don't think it would be a good idea to allow for longer expiration times, but I can imagine optionally paying less for shorter times makes sense. (Although I'm still not a fan of storing messages / message hashes in the blockchain, in my opinion it should be used for value-lookups of public interest only, like id -> GnuPG key or d -> IP address.) Also, a name_release command that returns the locked coins would be great - this could help in opening up more unused names again. For instance, I have at least one name which I would release if I could.

[snailbrain]

without longer expiration of names then namecoin automatically dismisses any use cases in which the user might not be able to renew his name every 36k blocks... for something sensitive or where money is involved, they just won't use namecoin.. which means less uptake..
what is the disadvantages of a longer expiration name (instead of just saying "no")? (bar staying in the block chain longer, although they would have paid for it)

also after more thought, i think shorter names being more expensive than longer names is a bit silly and over complicating things

edit: good that we have more people to discuss fees now

[domob]

without longer expiration of names then namecoin automatically dismisses any use cases in which the user might not be able to renew his name every 36k blocks... for something sensitive or where money is involved, they just won't use namecoin.. which means less uptake..
what is the disadvantages of a longer expiration name (instead of just saying "no")? (bar staying in the block chain longer, although they would have paid for it)

I'm not yet convinced that there really are usecases where you can't renew the name ever so often (36k blocks is not really a short time, IMHO). Ok, maybe you want your namecoin key to your domain name to be in cold storage or so, but if you are really that concerned about it, I don't think it would be asked too much to boot into a fresh system from some CD, sign the name_update transaction there and submit it from your main system with internet connection once per year. What are the other cases where you might not be able to renew the domain so often?

Apart from that, I think names are an important asset that should be available to best uses as much as possible. And even if someone paid more than usual for a longer expiration time (say 5 years), he may lose interest in the project or whatever he is doing earlier than that, so that the name stays unused for too long. A possible solution could be the following:

Require excessively high fees for longer expiration time (I think that the fees for, say 2 years, should in any case be more than twice the 1 year fees) so that only those who really need this feature do it (instead of renewing from time to time with ordinary fees), and possibly implement name_release which refunds some of the extra fees, so that people are encouraged to release no longer used names (instead of just forgetting about them and having them locked for a long time) if they really abandon projects or need names no longer.

also after more thought, i think shorter names being more expensive than longer names is a bit silly and over complicating things

Yes, it's a bit more complicated than a flat fee. But I really believe at least super-short domain names (1-3 letters) need to be more expensive than ordinary names in order to discourage hoarding/squatting in favour of actual applications that really want a particular name and are willing to pay more for it. (After all, people have reserved all 1-3 letter domain names, and are selling some of them for much more than the reservation fee. In my opinion this is making money for their benefit at the cost of the entire community, since they only paid the same amount as for a long name, but apparently shorter names have a higher preserved value.)

I do know that name squatting can't be prevented by that (because you can't find meaningful rules to also discourage people from squatting loads of trademarks or common words), but I think it would already help to make those very short names more expensive. After all, it is much cheaper at the moment to hold all 1-letter domain names than all 2-letter ones, but IMHO is much more valuable to do so. (Although holding 2-letter names is still quite desirable and rare, in my opinion.)

[moa]

I don't have much to contribute at this point except the following few points ;

- namespace ownership should expire without renewal or the blockchain could grow without bound from dead/forgotten db entries

- as much as you think you can envisage every use-case, that is probably impossible, so the best action is to only put those hard fees in place that prevent the system from becoming dysfunctional (an absolutely minimal technically justifiable set only) ... all other fees should be left up to the wisdom of the crowd to arrive at naturally.

[virtual_master]

Short names are definitely more valuable. But life is unfortunately not always fair.
The must important is to bring more traffic in the Namecoin system to gain value.
Would bring a length based fee more traffic ? If properly designed absolutely sure.
2 character domains are about 40 times more then 1 character based but they should cost only double.
3 character domains are about 40 times more then 2 character domains. .. and so on
How much additional work would be to implement a length based system compared with a flat one ?
and how much additional namecoins traffic volume would bring this system by the registration/renewal in 1 year ?

To have lower fee for id/ than for d/ seems reasonable.
Another point of view would be that the fee system should not be cheated.
If registration of id/ is much cheaper than d/ somebody could build a parallel system of DNS interpreting id/ as d/ and the fees would not flow in the Namecoin system.

[domob]

To have lower fee for id/ than for d/ seems reasonable.
Another point of view would be that the fee system should not be cheated.
If registration of id/ is much cheaper than d/ somebody could build a parallel system of DNS interpreting id/ as d/ and the fees would not flow in the Namecoin system.

Part of that later "problem" would be mitigated by making the fees for each namespace depend dynamically on how many names there currently are registered in the namespace (since the less names there are, the more are still available, and the less the "cost" is the community already has because of fewer names available). On the other hand, I can well imagine that if id/ takes off, much more IDs than domains could be registered at some point, and it would still not make sense to have IDs more expensive than domains (or would it?).

Regarding building a parallel system: I don't think that would be a problem. I mean, you can do that already - not because of lower fees, but since a lot of good d/ names are already taken, what stops me from registering a lot of "good" domob/ names, which are still free, and then promoting my own .domob TLD resolved to them with a custom Mozilla add-on or DNS server? IMHO that would be pointless, because for a DNS to gain value, there has to be a broad consensus about it. And I doubt that someone could get a majority of users to use his alternative resolver which cheats the namecoin system.

[khal]

Part of that later "problem" would be mitigated by making the fees for each namespace depend dynamically on how many names there currently are registered in the namespace (since the less names there are, the more are still available, and the less the "cost" is the community already has because of fewer names available). On the other hand, I can well imagine that if id/ takes off, much more IDs than domains could be registered at some point, and it would still not make sense to have IDs more expensive than domains (or would it?).

More registered names means less fees for each names. Otherwise you'll limit the maximum number of registrable names (for the locked fees).
Or is there a solution for this ?

I've a formula that is based on number of registered names and total number of coins minted (should be based on block number, easier to do bad idea, infinite growth) that follow this scheme. More on this later (1NMC to 3NMC for a total of 10k names, 0.11 to 0.54NMC for 100k names and 0.001NMC to 0.003NMC for 100 millions).

Regarding building a parallel system: I don't think that would be a problem. I mean, you can do that already - not because of lower fees, but since a lot of good d/ names are already taken, what stops me from registering a lot of "good" domob/ names, which are still free, and then promoting my own .domob TLD resolved to them with a custom Mozilla add-on or DNS server? IMHO that would be pointless, because for a DNS to gain value, there has to be a broad consensus about it. And I doubt that someone could get a majority of users to use his alternative resolver which cheats the namecoin system.

I'm mitigated about a per namespace fee (in locked coins or miner fees ?).
More used = more expensive ?

If would be feasible if coins go back to miners. But if a lot of coins go back to miners, there value will drop and the cost of locked fees wouldn't prevent spam anymore (if locked fees are 0.001% of normal fees for example). Is my logic wrong ? Could things equilibrate themselves in some way ?

[khal]

Require excessively high fees for longer expiration time (I think that the fees for, say 2 years, should in any case be more than twice the 1 year fees) so that only those who really need this feature do it (instead of renewing from time to time with ordinary fees), and possibly implement name_release which refunds some of the extra fees, so that people are encouraged to release no longer used names (instead of just forgetting about them and having them locked for a long time) if they really abandon projects or need names no longer.

Good idea (even a name_update will release extra fees by reusing them).

As said before, if we use only the amount of locked fees to calculate the expiration time, we will have some problems as this amount can increase or decrease over time.
An exponential cost of locked fees would reduce this problem by a lot because an exponential change in the total number of names will be very rare.

But, it also adds a lot of complexity to check if a name is expired or not, etc

Some other problems :
- if the expire time change constantlyi t('ll be a nightmare
- if the expire time change by steps of 36k blocks, you can be in the situation where your name will expire in 30k blocks and the next block it is expired by 6k blocks
- we must put a limit on the maximum expire time (X * 36k blocks)
- one can register 100k names now and let them expire

Namecoin has not be designed for that, can it be really adapted to this need without too heavy changes ?

[phelix]

My thoughts:

Your standard tx fee proposal sounds good except there should be no free TXs.
Nothing besides standard fees should ever go to miner because it can give weird incentives.

The coin on name_update needs to be destroyed forever. Otherwise it is not really a fee. Destroyed coins are not a problem atm and we could still keep block reward at 1NMC forever.

It needs to be simple.


About name expiry: We could add a concept of never expiring names into nmcontrol: Name: b/eurobond100_asdfsomerandas23 expires --> only the name that held it can create a valid new bond b/eurobond100_asdfsomeotherrandas45 Somewhat like colored names.