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 0389A910 for ; Fri, 26 May 2017 20:02:44 +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 96823180 for ; Fri, 26 May 2017 20:02:43 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 0612B135E1B; Mon, 12 Jan 1970 06:29:18 +0000 (UTC) To: Jacob Eliosoff , bitcoin-dev@lists.linuxfoundation.org References: From: Matt Corallo Message-ID: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> Date: Fri, 26 May 2017 20:02:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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 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 20:02:44 -0000 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 >