carrot
Image by keep_bitcoin_real
I don’t like arbitrarily chosen constants in code.
Sometimes they’re unavoidable and harmless. I use 11 in code I write when the number doesn’t matter (because eleven is my favorite number).
I like arbitrarily chosen constants in protocols even less, but sometimes they’re unavoidable. The 2mb block limit proposal has a few ‘magic’ numbers, but the 75% hash-rate threshold and the 28-day grace period generate the most discussion and debate.
Some people would rather the 75% be 95% or 99%. I think that is too high because it gives “veto power” to a single big solo miner or mining pool. Holding veto power is dangerous– somebody who disagrees with the change or just wants to disrupt Bitcoin might use extortion, bribery, or blackmail against a miner to try to prevent the change.
Other people think 75% is too high; after all, if 51% of hash power got together they could just choose to ignore blocks that vote ‘the wrong way’. If they are mining pools they might lose most of their miners, but they could.
Miners producing up-version blocks is a coordination mechanism. Other coordination mechanisms are possible– there could be a centrally determined “flag day” or “flag block” when everybody (or almost everybody) agrees that a change will happen.
Some people think a 28 day grace period is not long enough for businesses or people to upgrade, but I’ve contacted several of the major Bitcoin miners, exchanges, web-wallet providers and they are all confident four weeks is “plenty of time” for them to upgrade.
A longer grace period would be appropriate if mobile wallets needed to upgrade, because getting changes to apps approved and into the Apple or Android stores can take a while. But none of the popular mobile walle…
Gavin Andresen: Seventy-five, twenty-eight...
No comments:
Post a Comment