As for your stages idea, I generally like the idea (and mentioned it may be a good idea in my proposal), but am worried about scheduling two hard-forks at once....Lets do our first hard-fork first with the things we think we will need anytime in the visible future that we have reasonable designs for now, and talk about a second one after we've seen what did/didnt blow up with the first one.
Anyway, this generally seems reasonable - it looks like most of this matches up with what I said more specifically in my mail yesterday, with the addition of timewarp fixes, which we should probably add, and Luke's header changes, which I need to spend some more time thinking about. Matt On 02/09/16 14:16, jl2012--- via bitcoin-dev wrote: > I would like to present a 2-3 year roadmap to a better header format and > bigger block size > > Objectives: > > 1. Multistage rule changes to make sure everyone will have enough time to > upgrade > 2. Make mining easier, without breaking existing mining hardware and the > Stratum protocol > 3. Make future hardfork less disruptive (with Luke-Jr's proposal) > > Stage 1 is Segregated Witness (BIP141), which will not break any existing > full or light nodes. This may happen in Q2-Q3 2016 > > Stage 2 is fixes that will break existing full nodes, but not light nodes: > a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this > roadmap), potentially change the witness discount > b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts > c. (optional) Move segwit's commitments to the header Merkle tree. This is > optional at this stage as it will be fixed in Stage 3 anyway > This may happen in Q1-Q2 2017 > > Stage 3 is fixes that will break all existing full nodes and light nodes: > a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the > rules and activation logic should be included already > b. Change the header format to Luke-Jr's proposal, and move all commitments > (tx, witness, etc) to the new structure. All existing mining hardware with > Stratum protocol should work. > c. Reclaiming unused bits in header for mining. All existing mining chips > should still work. Newly designed chips should be ready for the new rule. > d. Fix the time warp attack > This may happen in 2018 to 2019 > > Pros: > a. Light nodes (usually less tech-savvy users) will have longer time to > upgrade > b. The stage 2 is opt-in for full nodes. > c. The stage 3 is opt-in for light nodes. > > Cons: > a. The stage 2 is not opt-in for light nodes. They will blindly follow the > longest chain which they might actually don't want to > b. Non-upgraded full nodes will follow the old chain at Stage 2, which is > likely to have lower value. > c. Non-upgraded light nodes will follow the old chain at Stage 3, which is > likely to have lower value. (However, this is not a concern as no one should > be mining on the old chain at that time) > > ------------------------------- > An alternative roadmap would be: > > Stage 2 is fixes that will break existing full nodes and light nodes. > However, they will not follow the minority chain > a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount > b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts > c. Change the header format to Luke-Jr's proposal, and move all commitments > (tx, witness, etc) to the new structure. > This may happen in mid 2017 or later > > Stage 3 is fixes that will break all existing full nodes and light nodes. > a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade > again, as the rules and activation logic should be included already > b. Reclaiming unused bits in header for mining. All existing mining chips > should still work. > c. Fix the time warp attack > This may happen in 2018 to 2019 > > Pros: > a. The stage 2 and 3 are opt-in for everyone > b. Even failing to upgrade, full nodes and light nodes won't follow the > minority chain at stage 2 > > Cons: > a. Non-upgraded full/light nodes will follow the old chain at Stage 3, which > is likely to have lower value. (However, this is not a concern as no one > should be mining on the old chain at that time) > b. It takes longer to implement stage 2 to give enough time for light node > users to upgrade > > ------------------------------- > > In terms of safety, the second proposal is better. In terms of disruption, > the first proposal is less disruptive > > I would also like to emphasize that it is miners' responsibility, not the > devs', to confirm that the supermajority of the community accept changes in > Stage 2 and 3. > > Reference: > Matt Corallo's proposal: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403. > html > Luke-Jr's proposal: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377. > html > > > > > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
