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 893CB4A4 for ; Fri, 26 May 2017 21:30:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FB27E4 for ; Fri, 26 May 2017 21:30:38 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id l18so27763260oig.2 for ; Fri, 26 May 2017 14:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8WIzNNJYSK7/fkZfv/A6XAUkxCnARwQFnkABjYQqABU=; b=RGX+ODOQIy3yhLRjoMmFDrY7i7baqeMIZlIuDiKYjQdXYOTmtGslIolnVqvbJVZhsQ 3ptK1TuoWD0wKUHET9F1QrjetUX32N0Sk6u1+Yq5ASYJvUKlzgBUW3lIgqDJJrKdLNDK OAykWEUZzCmPNP6tF8GrQRrCSxrm3xaz8hz/lMnHfDQnc7nxIRZA2APetxjMoE7w65Nh z698Q4q7C8RztKMU73X2jyNJxglxHoe0LervfnpbOU6Ct6fW3fZ8NLUVbL/sCzMnO3o7 2EWxmTVLcOiGXuZc3iE4pa6Vk/h4yovWUev0Cw7g/6wazgzxbCi4NeoiC0VJrdj7YIZ6 O3Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8WIzNNJYSK7/fkZfv/A6XAUkxCnARwQFnkABjYQqABU=; b=gJqbDzaOsYfHZzGqXDVcqAY8YHNbNoeFUYTf46t2L3UyYnAfJEPD+XDfv4zCDXVd9N zT9sYTNr19O1XbH6iIpGmzFlsmNtWSwshGuyyDgOxkdSU4CUDt+JWYt9ZAw1BTRLHaZ9 oLXIUaIXrhyDMfaoTvX8PoCZjWmsCoIYm8pJGmaTVrn2AMahulxJ8iPvCPvLf51wlKqw jBOa0XqYuTx6w3TSt095N1yuImUsTzxT2iv5OiUxgK9Q4VswUgrjJqO5CXEamI1DjaPi ax/+1RwHUeEcFIqI0l8FnYNTparKTkAhb0EsTrlWxE5QqwYmlUBBCu1BhZSxlcKPSAbm EbCw== X-Gm-Message-State: AODbwcD6EsFU/6wr40k78tWHFIENYRErKpGkJv+9ARX4Z4ovo/9wYEci n/rpnUGgtFms1mzs8B++QVCzSEmwaw== X-Received: by 10.157.14.230 with SMTP id 93mr2286819otj.97.1495834237696; Fri, 26 May 2017 14:30:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.198 with HTTP; Fri, 26 May 2017 14:30:37 -0700 (PDT) In-Reply-To: References: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> From: James Hilliard Date: Fri, 26 May 2017 17:30:37 -0400 Message-ID: To: Jacob Eliosoff Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no 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 21:30:39 -0000 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). 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. 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. This is why the mandatory signalling period is needed. 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. Use BIP91 or similar to activate BIP141 via mandatory signalling ASAP(likely using bit 4) 2. Develop HF code based on assumption that BIP141 is active so that you only have to test the BIP141->HF upgrade/activation codepath. 3. 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). By doing a staged rollout of segwit and then a HF you get a single testable upgrade path. 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. 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. Just when Segwit2MB support reaches 80%, those 80% > join everyone else in signaling for BIP141. BIP91 orphaning is an optional > addition but my guess is it wouldn't be needed. > > > 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. >> >> 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. >> >> 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. >> >> Matt >> >> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: >> > Forgive me if this is a dumb question. Suppose that rather than >> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in >> > just triggered BIP141 signaling (plus later HF). 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. My focus here is how >> > incompatibility with existing nodes could be minimized. >> > >> > (BIP91 could also be used if BIP141 support still fell short of 95%. >> > But if Segwit2MB support reaches 80%, it seems likely that an additional >> > 15% will support BIP141-without-HF.) >> > >> > >> > _______________________________________________ >> > 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 >