Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

From: Matt Corallo <lf-lists@mattcorallo•com>
To: jl2012@xbt•hk, bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger block size
Date: Tue, 9 Feb 2016 22:15:15 +0000	[thread overview]
Message-ID: <56BA64F3.2060900@mattcorallo.com> (raw)
In-Reply-To: <239b01d16344$717712d0$54653870$@xbt.hk>

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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 