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 63AD4BF5 for ; Fri, 26 May 2017 17:47:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D426317C for ; Fri, 26 May 2017 17:47:13 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id h4so9671011lfj.3 for ; Fri, 26 May 2017 10:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nUIUAUK1q2IV0vnJw7GxQQphpKUuQvRpYpoC/lL+H9k=; b=AJ1RZkiGSrEPPs7a2UExlgd3ttOZ/wBmnDe/s/mfN2y2ZRug43oDdk9Ni7b6aCYdp8 tXqvur3qEA2ft5A/Y7zPSQxmooAyD4ze0jW10QT7qy1cf/5xfouo9jczhTbUgygrf32L AZtBzkO3MJHdxfsc9E27x9GRsnp7LyYpY/CvTyz/vd3E3jnjeoDcCUDzYKnarOh81bju AYx7ZG+l6eoFq3PlxIoLzKQ2HnR6axBc4Id575a1IGLS62eAFwBl8OniEb1xQ5z5HuVY GzJ5sHcJSKpSx8k2TiQvE41MUw6BjPkt7mK/CumDMC592/2Q0l/QWf+rnymOMOvDtEE3 H9Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nUIUAUK1q2IV0vnJw7GxQQphpKUuQvRpYpoC/lL+H9k=; b=CIpTCSQ1dBno0TYm5UwXd0liUgNyZygd+6DVUiVDaw8FsP2xgJSKNvw0sDTxKbcJOg j0/e9aKEm+dj++M9km0IEryurh2GHQ5amF7h9D9KvsmAsnl6I6VgkVnH0vsku8qPvLAd Uq9oLhMSx5oErEWbeeR9nPCX8pwdMh/CJJxEfToe9t7YuJspOrvtOfhq7yY8jTmXIEuQ /1sidHuJsZNkwwjY0b/4IOKUlOY9Etdq0mrZJ4NFQ6yeFE8GBITGpuXIHfy6vb+vb1Aw 7tYqvDB/vtLsogakAPwXIGOy7oXwglelxZCuIqpzDeku28HGg67UbsttSzZh7u9uVZjC ywGw== X-Gm-Message-State: AODbwcA+v52YkMMEETpgj/hHxOD7Jazly4/T5lLSvMe5NsSBgnFbesvH IhmHX/eDiywnUzlgkIZxInCUj1Lw+8Ydank= X-Received: by 10.25.157.147 with SMTP id g141mr906060lfe.125.1495820832087; Fri, 26 May 2017 10:47:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.80.4 with HTTP; Fri, 26 May 2017 10:47:11 -0700 (PDT) From: Jacob Eliosoff Date: Fri, 26 May 2017 13:47:11 -0400 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="001a11402b085824ec055070ed9b" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 X-Mailman-Approved-At: Fri, 26 May 2017 18:35:39 +0000 Subject: [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 17:47:14 -0000 --001a11402b085824ec055070ed9b Content-Type: text/plain; charset="UTF-8" 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.) --001a11402b085824ec055070ed9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgive me if this is a dumb question.=C2=A0 Suppose that = rather than directly activating segwit, the Silbert/NYC Segwit2MB proposal&= #39;s lock-in just triggered BIP141 signaling (plus later HF).=C2=A0 Would = that avoid incompatibility with existing BIP141 nodes, and get segwit activ= ated sooner?=C2=A0 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: t= he 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 Segwit= 2MB nodes and any remaining BIP141 nodes, etc.=C2=A0 My focus here is how i= ncompatibility with existing nodes could be minimized.

(BIP91 could = also be used if BIP141 support still fell short of 95%.=C2=A0 But if Segwit= 2MB support reaches 80%, it seems likely that an additional 15% will suppor= t BIP141-without-HF.)
--001a11402b085824ec055070ed9b--