Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-17 📝 Original message:Although I agree that how ...
📅 Original date posted:2015-12-17
📝 Original message:Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.
BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?
1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation
2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.
Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).
Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/e44914d7/attachment.html>;
📝 Original message:Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.
BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?
1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation
2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.
Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).
Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/e44914d7/attachment.html>;