Hmm, what is the point of 1. and 2. if they get overwritten in 3. ? IMHO 3. to 5. would be enough.
I forgot a '+' in 3.
Miners are not bound by priority. Eleuthria said himself BTCGuild was experimenting with completely ignoring priority, could be they already use it for production by now (for Bitcoin).
So by the very small advantage of occasionally saving a small fee you make fee calculation unpredictable voodoo, make things more complicated for pool ops and have a good chance of delaying your txs in the future. I have a strong opinion on this issue: priority is bad at this point.
(It would be good if miners would still prefer high priority txs as long as they pay reasonable fees because that makes block flooding more difficult).
There is an additional rule at the end of the fee function to require more and more fees is block has reached 50% of its size. So, more fees, more chances to be in the next block in case of flood.
? I thought txIns would decrease the fee?
I first proposed that but there are 3 problems :
- each txIn is where the signature will be verified, and it costs CPU
- if you have 50 txIn and 50 txOut, you'll pay 0 (50-50) additional fee on this part
- you can send 1000 tx to yourself for "free" (1000 small tx) and then consolidate to yourself (1000 txIn 1 txOut) for "free"
So, here is what can be done for txOut/txIn :
fee += (nb txOut - 2) * baseFee + (nb txIn - 2 * baseFee / 2)
Just realized there is a problem with giving name_op fees to the miner that solves the block: miners can make a business of selling name registration much cheaper. It is profitable for them down to about 2% of the fee (orphaned blocks being the limit). So fees should be distributed to several miners... which might still give weird incentives.
Binding/locking a deposit contradicts the point of the fee. Until distribution to miners can be done in a proper way I vote for locking indefinitely / destroying.
So, we need to enforce the 0.01NMC (or wathever value we chose) of name_new. And forget the fees based on the size of the name...
[...]
c) If you name_update before anybody else does a name_new, the expiry field resets to 36,000.
[...]
Does this really work? I thought I tried and it did not... Would be nice if it did.
Not if the name is expired (he may not spoke about that case). Not sure it would be a good idea.