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 ACC2440A for ; Fri, 26 May 2017 22:44:48 +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 B187A168 for ; Fri, 26 May 2017 22:44:47 +0000 (UTC) Received: from [33.253.80.67] (unknown [172.56.18.219]) by mail.bluematt.me (Postfix) with ESMTPSA id EEA6A135E1B; Mon, 12 Jan 1970 09:11:22 +0000 (UTC) Date: Fri, 26 May 2017 22:44:44 +0000 In-Reply-To: References: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: James Hilliard , Jacob Eliosoff From: Matt Corallo Message-ID: <18D47015-A4F0-438C-8D46-812E3F20EE2B@mattcorallo.com> 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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 22:44:48 -0000 While I'm not 100% convinced there are strict technical reasons for needing= to wait till after segwit is active before a hard fork can be started (you= can, after all, activate segwit as a part of the HF), there are useful des= ign and conservatism reasons (not causing massive discontinuity in fee mark= et, handling major system changes one at a time, etc)=2E Still, totally agree that attempting to design, code, and test a new hard = fork in six months, let alone deploy it, let alone simultaneously with segw= it, is a joke and fails to take seriously the investment many have made in = the bitcoin system=2E Previous, rather simple, soft forks required similar = if not more development time, not counting deployment and activation time= =2E If the community is unable to form consensus around segwit alone for polit= ical reasons, further research into hard fork design may help, but even for= ks tied together would nearly certainly need to activate months apart=2E On May 26, 2017 5:30:37 PM EDT, James Hilliard wrote: >Mandatory signalling is the only way to lock in segwit with less than >95% hashpower without a full redeployment(which for a number of >technical reasons isn't feasible until after the existing segwit >deployment expires)=2E There's no reason not to signal BIP141 bit 1 >while also signalling bit 4, but you would want to use bit 4 to >coordinate bit 1 mandatory signalling=2E > >It would not be feasible to schedule any HF until one can be >completely sure BIP141 is active(at least not without waiting for the >timeout and doing a redeployment) due to activation/p2p codepath >complexity=2E This is why the mandatory signalling period is needed=2E > >Since it is likely a HF will take months of development and testing I >see this or something similar as the fastest safe path forward: >1=2E Use BIP91 or similar to activate BIP141 via mandatory signalling >ASAP(likely using bit 4) >2=2E Develop HF code based on assumption that BIP141 is active so that >you only have to test the BIP141->HF upgrade/activation codepath=2E >3=2E Deploy HF after BIP141 lock in(bit 4 can be reused again here since >this will be after BIP91 expiration) > >When rolling out some features it often makes sense to combine them >into a single fork for example BIP's 68, 112, 113 were rolled out at >the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF >has required features that would conflict with with features in the >segwit rollout which is why attempting to simultaneously deploy them >would cause major complexity/testing issues(you would have to deal >with feature conflict resolution for multiple potential activation >scenarios)=2E By doing a staged rollout of segwit and then a HF you get >a single testable upgrade path=2E > >Based on past development experiences I wouldn't expect a 6 month >timeline to be realistic for a properly tested HF, but this proposed >upgrade path should be the fastest available for both SegWit and a HF >regardless=2E > >On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev > wrote: >> Just to clarify one thing, what I described differs from BIP91 in >that >> there's no orphaning=2E Just when Segwit2MB support reaches 80%, those >80% >> join everyone else in signaling for BIP141=2E BIP91 orphaning is an >optional >> addition but my guess is it wouldn't be needed=2E >> >> >> On May 26, 2017 4:02 PM, "Matt Corallo" >wrote: >>> >>> Your proposal seems to be simply BIP 91 tied to the >>> as-yet-entirely-undefined hard fork Barry et al proposed=2E >>> >>> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, >as >>> you propose, would make the deployment on the incredibly short >timeline >>> Barry et al proposed slightly more realistic, though I would expect >to >>> see hard fork code readily available and well-tested at this point >in >>> order to meet that timeline=2E >>> >>> Ultimately, due to their aggressive timeline, the Barry et al >proposal >>> is incredibly unlikely to meet the requirements of a >>> multi-billion-dollar system, and continued research into meeting the >>> spirit, not the text, of their agreement seems warranted=2E >>> >>> Matt >>> >>> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: >>> > Forgive me if this is a dumb question=2E Suppose that rather than >>> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's >lock-in >>> > just triggered BIP141 signaling (plus later HF)=2E Would that avoid >>> > incompatibility with existing BIP141 nodes, and get segwit >activated >>> > sooner? Eg: >>> > >>> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals >support >>> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)" >>> > - If bit 4 support reaches 80%, it locks in two things: the >scheduled HF >>> > (conditional on segwit), and *immediately* turning on bit 1 >(BIP141 >>> > support) >>> > >>> > I realize this would still leave problems like the aggressive HF >>> > schedule, possible chain split at the HF date between Segwit2MB >nodes >>> > and any remaining BIP141 nodes, etc=2E My focus here is how >>> > incompatibility with existing nodes could be minimized=2E >>> > >>> > (BIP91 could also be used if BIP141 support still fell short of >95%=2E >>> > But if Segwit2MB support reaches 80%, it seems likely that an >additional >>> > 15% will support BIP141-without-HF=2E) >>> > >>> > >>> > _______________________________________________ >>> > bitcoin-dev mailing list >>> > bitcoin-dev@lists=2Elinuxfoundation=2Eorg >>> > https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev >>> > >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists=2Elinuxfoundation=2Eorg >> https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev >>