I like that the formula for the fee is well defined, but I'm worried about having a moving window like that. Consider if I submit a name transaction with the bare minimum fee, but it doesn't make it into the next block. By the next block, the median may have changed, and my previously valid name registration is now wasted.biolizard89 wrote: 3. The enforced fee is the median of the 2048 previous votes. (This number is chosen mainly for the balance between stability against randomness and flexibility against market instability. The exact number is open to debate.)
Can you elaborate on why they would choose default settings? If they're given freedom to choose, I assume they will reasonably price things to maximize their rewards.biolizard89 wrote: 5. Most miners will choose to use the default settings from the Namecoin dev team assuming that they are reasonable (similar to Bitcoin tx fees).
I do like that.biolizard89 wrote: 6. If the Namecoin dev team does something unpopular with tx fees, the community of miners can choose not to honor it, which acts as a check on the power of the Namecoin dev team.
I definitely agree with 1, but 2's effects are so disconnected from the action, I'm not sure miners will really take this into account. *Luckily* there's also 3 which is "miners want to maximize their reward".biolizard89 wrote: 7. Miners have an incentive to (1) not make the name fees so high that people won't want to pay them (because then they won't collect tx fees); and (2) not make the name fees so low that Namecoin is devalued due to squatting (because then the exchange rate will go down, which impacts the collected tx fees).
I like that as well.biolizard89 wrote: 9. The data structure could support varying fees for different names, in terms of namespace, name length, and/or value length. This is not a requirement of the proposal, but I think it could potentially be useful.
Does this really punish squatters disproportionately to legitimate users?biolizard89 wrote: 10. The data structure could support name fees on renewals. This makes things harder for squatters, since holding onto a name would have a recurring fee. This is not a requirement of the proposal, but I think it could potentially be useful. (If we started requiring name fees on renewals, I'm not sure if that would require an initial hardfork... my guess is that it could be done without a hardfork, but I don't know enough to be sure... can snailbrain or khal comment on this?)
I'm all for slow deflation, but I'm not sure I want to be destroying coins when it's avoidable, unless we counter act that with an infinite supply of Namecoins. Effectively though what I'd prefer is to just award them to miners.biolizard89 wrote: 11. We would not have to return locked coins to name holders after names expire. As coins are destroyed, the USD price of Namecoin would go up slightly (small amount of deflation), and the name price would decrease accordingly (so that the NMC price of a name will decrease as the supply decreases, meaning we will never run out of coins). This makes things harder for squatters, since they can't squat a name, and then get their money back if no one wants to purchase it. This is not a requirement of the proposal, but I think it could potentially be useful.
Anyways I like the idea overall, but I'm a bit worried about the implementation, specifically with regards to insufficient fees.
EDIT: I decided to omit it earlier, but I had a proposal for an alternative to a moving window, but this may not be any better. Basically the fee proposals to be examined are taken from the past two "chunks" of 1024 blocks. So if the last block mined was 10239 the two intervals considered would be 7168 to 8192 and 8192 to 9216. Then, once block 10240 is mined, the two intervals would be 8192 to 9216 and 9216 to 10240. So you have complete certainty of the minimum fee for 1024 blocks at a time, but it introduces significant uncertainty near the edges of intervals. I'm not positive it's an improvement but I thought I'd throw it out there.
In python it uses
Code: Select all
def interval(h, x=0): return ((h // 1024) - x) * 1024
Code: Select all
[interval(last_known_block, x) for x in xrange(3)]