This looks very interesting. The first time implementing it might be more painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks after the block height in coinbase? That would make it easier to use it as activation threshold of consensus rule changes. For the witness commitment, it will also be treated as a merge mined commitment? It is also good to emphasize that it is the responsibility of miners, not devs, to ensure that the hardfork is accepted by the supermajority of the economy. -----Original Message----- From: bitcoin-dev-boun...@lists.linuxfoundation.org [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Luke Dashjr via bitcoin-dev Sent: Sunday, 7 February, 2016 17:53 To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork Here's a draft BIP I wrote almost a year ago. I'm going to look into revising and completing it soon, and would welcome any suggestions for doing so. This hardfork BIP aims to accomplish a few important things: - Finally deploying proper merge-mining as Satoshi suggested before he left. - Expanding the nonce space miners can scan in-chip, avoiding expensive calculations on the host controller as blocks get larger. - Provide a way to safely deploy hardforks without risking leaving old nodes vulnerable to attack. https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
