Discussion for revised fees
Posted: Tue Jun 25, 2013 9:36 pm
First, I'll start by summarizing the name_* characteristics.
name_new
- include 20 bytes of data (a hash) : can be any value, be used as clear text
- no limit on their number : you can issue as many as you want
- cost 0.01NMC (locked), but the network doesn't force any value
- cost standard tx fees
name_firstupdate/name_update
- the name_new 0.01NMC coins must be moved with each tx (locked)
- includes 520 bytes of data max (should have been 1k, but it is bugged)
- limited to 1 per block per name
- cost standard tx fees
Advantages of this system :
- miners can't get free names because of locked coins (but, see limits below)
- anybody can use a name_new to send 20 bytes of data
Limits of this system :
- name_new is expensive (due to the locked coins for name_(first)update) compared to the space used
- anybody can change the value of the name_new to have almost free domains (the dust spam limit prevents this a bit)
- 520 characters is too small (will be changed to 9k)
- name(first)update cost only a standard tx fee
Locked coins (lost when the name expires) is not the best idea, but is an easy one. That's why it was chosen I guess.
The only way to prevent both lost coins and free names for miners is to lock coins and release them when the name expires (it means coins must follow each name_update tx, as now, and a final name_release get them back, this would also allow people to release a name before it ends).
As name_update should not be free, it must also have an additional fee. I guess we can't add the same amount as name_new to locked coins for each name_update as we would end with names with locked value of hundreds of NMC :p (And it would be cheaper to let the name expire and get it back... and impossible to sell at a reasonable price)
Fees should still have an acceptable value if nmc price do x10 or /10.
Proposed fees :
* standard transaction
- standard fees
* name_new :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked fees, paid once here, value should not be enforced here)
* name_firstupdate :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked, paid in name_new but could increase/decrease with time, value should be enforced here)
* name_update :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked, paid in name_new but could increase/decrease with time, value should be enforced here)
* name_release :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees unlocked (back to your balance)
Fees details :
* standard fees :
- baseFee per KB * sqrt(KB) : more data in one tx = more expensive (Even a big standard tx will cost harddisk space and names will be able to store up to 9k of data)
- baseFee per txIn above the second
- baseFee*2 per txOut above the second
- baseFee*4 per dust txOut
- small tx can be free
* name fees :
Name fee : should be based on baseFee (used in standard tx). That way, we only need to update one value to update all fees.
Exists because a name_* operation should always cost something to the user.
- baseFee per KB again ?
- baseFee, required
A big name tx will have high standard tx + those fees, so this one does not need to be particularly high.
* registration fee :
Registration fee : is the cost for scarcity of names.
As they are locked, they limit the maximum number of names (should not be too high).
They could change at each name_update.
The cost of one/several name_update can can be pre-sent in name_new (for automatic name_firstupdate & renewal) and the name_firstupdate pre-created.
They could be adapted to the name length and other params (it must remain simple & fast for the node to calculate)
If this value is dynamic, it can be enforced by the network
What do you think ?
Comments will be highly appreciated :p
name_new
- include 20 bytes of data (a hash) : can be any value, be used as clear text
- no limit on their number : you can issue as many as you want
- cost 0.01NMC (locked), but the network doesn't force any value
- cost standard tx fees
name_firstupdate/name_update
- the name_new 0.01NMC coins must be moved with each tx (locked)
- includes 520 bytes of data max (should have been 1k, but it is bugged)
- limited to 1 per block per name
- cost standard tx fees
Advantages of this system :
- miners can't get free names because of locked coins (but, see limits below)
- anybody can use a name_new to send 20 bytes of data
Limits of this system :
- name_new is expensive (due to the locked coins for name_(first)update) compared to the space used
- anybody can change the value of the name_new to have almost free domains (the dust spam limit prevents this a bit)
- 520 characters is too small (will be changed to 9k)
- name(first)update cost only a standard tx fee
Locked coins (lost when the name expires) is not the best idea, but is an easy one. That's why it was chosen I guess.
The only way to prevent both lost coins and free names for miners is to lock coins and release them when the name expires (it means coins must follow each name_update tx, as now, and a final name_release get them back, this would also allow people to release a name before it ends).
As name_update should not be free, it must also have an additional fee. I guess we can't add the same amount as name_new to locked coins for each name_update as we would end with names with locked value of hundreds of NMC :p (And it would be cheaper to let the name expire and get it back... and impossible to sell at a reasonable price)
Fees should still have an acceptable value if nmc price do x10 or /10.
Proposed fees :
* standard transaction
- standard fees
* name_new :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked fees, paid once here, value should not be enforced here)
* name_firstupdate :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked, paid in name_new but could increase/decrease with time, value should be enforced here)
* name_update :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees (locked, paid in name_new but could increase/decrease with time, value should be enforced here)
* name_release :
- standard fees (go to miners)
- name fees (go to miners)
- registration fees unlocked (back to your balance)
Fees details :
* standard fees :
- baseFee per KB * sqrt(KB) : more data in one tx = more expensive (Even a big standard tx will cost harddisk space and names will be able to store up to 9k of data)
- baseFee per txIn above the second
- baseFee*2 per txOut above the second
- baseFee*4 per dust txOut
- small tx can be free
* name fees :
Name fee : should be based on baseFee (used in standard tx). That way, we only need to update one value to update all fees.
Exists because a name_* operation should always cost something to the user.
- baseFee per KB again ?
- baseFee, required
A big name tx will have high standard tx + those fees, so this one does not need to be particularly high.
* registration fee :
Registration fee : is the cost for scarcity of names.
As they are locked, they limit the maximum number of names (should not be too high).
They could change at each name_update.
The cost of one/several name_update can can be pre-sent in name_new (for automatic name_firstupdate & renewal) and the name_firstupdate pre-created.
They could be adapted to the name length and other params (it must remain simple & fast for the node to calculate)
If this value is dynamic, it can be enforced by the network
What do you think ?
Comments will be highly appreciated :p