From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FBF2F3C for ; Tue, 9 Feb 2016 22:15:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56CD413D for ; Tue, 9 Feb 2016 22:15:18 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 34ACE5CDB2; Tue, 9 Feb 2016 22:15:17 +0000 (UTC) To: jl2012@xbt.hk, bitcoin-dev@lists.linuxfoundation.org References: <239b01d16344$717712d0$54653870$@xbt.hk> From: Matt Corallo X-Enigmail-Draft-Status: N1110 Message-ID: <56BA64F3.2060900@mattcorallo.com> Date: Tue, 9 Feb 2016 22:15:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <239b01d16344$717712d0$54653870$@xbt.hk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 09 Feb 2016 22:16:25 +0000 Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger block size X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:15:19 -0000 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 >