Seventy-five, twenty-eight…
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 wallets are affected by a change to the block size limit.
We can look at the adoption of the last major Bitcoin core release to guess how long it might take people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty eight days later, about 38% of full nodes were running that release. Three months later, about 50% of the network was running that release, and six months later about 66% of the network was running some flavor of 0.11.
I expect adoption of the 2mb change will be faster, because once 50% of hashpower supports the change Bitcoin Core will complain “This version is obsolete; upgrade required!”.
28 days is plenty of time for hashpower to upgrade. At the last block version upgrade (for BIP 65), it took about a month to get to 75% of hashpower, then less than seven more days to reach 95%. By the end of the grace period, I would expect over 99% of hashpower to be ready for the first bigger-than-one-megabyte block.
