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 EF3DEC16 for ; Fri, 26 May 2017 20:10:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F49118F for ; Fri, 26 May 2017 20:10:41 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id m18so11323499lfj.0 for ; Fri, 26 May 2017 13:10:40 -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=TiU9UIZ8u/a+6rpVxRXt1+rW+Iy01hiRGREkgNOr4oc=; b=bcbvWueTCJYdFT00ZnX4AiUyVRr7Nfo93pc2TPzUDdqcyiRXGlqHQxtnF+zntbb3Fn 6MAhZWCCDIJAqXBKxWr1AuS+gAbDC6FNy+5bUCeNmMpZOzRFCD37xC4dziBLb/PALq2D 5uBz11VD+XWqz8235lMhkFhB61wsSDuA3Z+UdAn7c3RPkrOFMG3bVPG+tm2zhp/aNLdG 7/enTXZKgAgNhHbofdnP1zUhrsouEFjxTAa7R/ZYYHo1X4lGzD4Z4xXvSezChPLFYkDe f5dKyHuglMfek8WkSrC7TKNzCnf9aeuF7gbmUU2Z+AZTjntoVWxbc4/PnKB5rl4p5z7M VpTw== 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=TiU9UIZ8u/a+6rpVxRXt1+rW+Iy01hiRGREkgNOr4oc=; b=h6ezcA3sJK9zuinGHf5sPIDfHKIHMUfkvZ5HeW+BaSxgipySm8gBc22YIdtJdS/Uij ZZbECxLxEW7g2majesz6polQ+VDYQ61EzSiYc44/cz6+UvIXKBuAxD2TYevExm8a4kZ9 jdAjovphq9RaD7LOZ0858XdjKIFVxYtr74UY1fndgatyed8jGF+sH2akthrLUVVMwjAw sOjHD9oN4E3Qv1lZ6gPY5FWQY55/auCF9EwgaYbsS3Bx6gv59Zs0HPLv+l7lyRo/ekYc PCLD2OqccOyk9IZ30F1V1+U72hUsYbT6Mq2ZmO2MXhnukVYKddxxbZz8KaGXb8OzxAvB 2nQg== X-Gm-Message-State: AODbwcDU1LzI1vRwiZ7BLxeQl8dg0mAHV0JborganQiGmftllMqlQn4p yQCo5CjZzGgSgfQ/KJZALvf25E8hMwd/ X-Received: by 10.25.202.27 with SMTP id a27mr1035887lfg.70.1495829439471; Fri, 26 May 2017 13:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.80.4 with HTTP; Fri, 26 May 2017 13:10:38 -0700 (PDT) Received: by 10.25.80.4 with HTTP; Fri, 26 May 2017 13:10:38 -0700 (PDT) In-Reply-To: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> References: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com> From: Jacob Eliosoff Date: Fri, 26 May 2017 16:10:38 -0400 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="f403045ea59c626895055072ee5c" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Fri, 26 May 2017 20:13:15 +0000 Cc: bitcoin-dev@lists.linuxfoundation.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:10:42 -0000 --f403045ea59c626895055072ee5c Content-Type: text/plain; charset="UTF-8" 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 > > > --f403045ea59c626895055072ee5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to clarify one thing, what I described differs from = BIP91 in that there's no orphaning.=C2=A0 Just when Segwit2MB support r= eaches 80%, those 80% join everyone else in signaling for BIP141.=C2=A0 BIP= 91 orphaning is an optional addition but my guess is it wouldn't be nee= ded.


On May 26, 2017 4:02 PM, "Matt Corallo" <= lf-lists@mattcorallo.com>= ; wrote:
Your propos= al 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<= br> 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.=C2=A0 Suppose that rather than<= br> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's l= ock-in
> just triggered BIP141 signaling (plus later HF).=C2=A0 Would that avoi= d
> incompatibility with existing BIP141 nodes, and get segwit activated > sooner?=C2=A0 Eg:
>
> - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support<= br> > 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 su= pport)
>
> I realize this would still leave problems like the aggressive HF
> schedule, possible chain split at the HF date between Segwit2MB nodes<= br> > and any remaining BIP141 nodes, etc.=C2=A0 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 addition= al
> 15% will support BIP141-without-HF.)
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--f403045ea59c626895055072ee5c--