Return-Path: <earonesty@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81A9698A for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 27 Jun 2017 19:26:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3FB8E5 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 27 Jun 2017 19:26:37 +0000 (UTC) Received: by mail-qt0-f177.google.com with SMTP id f92so32955709qtb.2 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 27 Jun 2017 12:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Wlu538f8oZ/2rVlCh9JrNXaGtcONvU6L6DbNgxPFRPg=; b=cpkyn9tZGJ/EyBP+Z0myyYE8slnCZf0tW1BclAc4XMP+JqGnA7msCYbKrkxQg7VMUt T/hxCJOzHKazdXLbawBKXJHHXuW+O+OpoMjze/vQhHd2iWcjFjRgKTMfooI2uInk27TF HH7pedf+cqP11f0OHnU7L/dgA22KLa7jWFhQHimkBh0h9jTzSIzpdGDERvwf1XFO+qIf IautgS7pfR2fnt8kHP34kk+4KjpzmBcx2Q/In6Yel2LkshXdVnC1TUubh6/OM21zE3pN 31033mnFBjSH1uzPVM4VBx3xLVpLdU6cnLn/nA9pJj994QxkhgJpG6YEc666EAcXC6/n t66A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Wlu538f8oZ/2rVlCh9JrNXaGtcONvU6L6DbNgxPFRPg=; b=gn5RaDMb8jNofmY0mRRHwxLrvdgrsKo7IZqA3DpoaZNW6LMvcE5zLU8AoOx+6rxczd MZq51ylN1gFCdp7S+3F834RGrnEPpQZSg9/1fctlrt4j/5UQN/XEEG83Dmt69VPZwT6l EUEe1+n+3UXm6t1TiMJNkp/dXEeixk9rJ600ly6srwLWV+isyHfvp3PNXJ/Qbz9swVWS G3OzGi2k9kNfImnoUISYMU1VW15ofPkWBS71irvMiQ6VpmCoTQb1TGwyrMVvBepjvTsI a/6C46lPHnVuQPDuLI1uUp8IYUCRqlrFcvxjeaiFiSIX4gDM2W4IL14i8FKmX6/c5xgO LO2A== X-Gm-Message-State: AKS2vOwLHLF/mP25ce+o9OE5Jvc0SF1lxZbAnXWvXZklWKPnlugyRN2f ppo5s7IuxA1zUysvegM/LeRcb5Xtfw== X-Received: by 10.200.10.206 with SMTP id g14mr6618131qti.227.1498591596818; Tue, 27 Jun 2017 12:26:36 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.237.54.100 with HTTP; Tue, 27 Jun 2017 12:26:35 -0700 (PDT) In-Reply-To: <CABm2gDrBOSWnqW_vZ-cibMFe8FqJmVChws-Vt7eMFzpfsx-7mQ@mail.gmail.com> References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com> <CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com> <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com> <CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com> <BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org> <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com> <CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@mail.gmail.com> <CAOG=w-tPgJ5baaNiZC5rTs_y=eV7AU+F=aGaH+uObqaB-VgL2w@mail.gmail.com> <CAAUaCyijF1eHSffUYf9Mrv+KP5H+NLBcy5MEhMUyT6Rxcbx93g@mail.gmail.com> <CAKzdR-rvP9RLJ=qGDMVyOT3WVqp7q2tUPpzbaQZ=wStsFSCbWA@mail.gmail.com> <CABm2gDrBOSWnqW_vZ-cibMFe8FqJmVChws-Vt7eMFzpfsx-7mQ@mail.gmail.com> From: Erik Aronesty <erik@q32.com> Date: Tue, 27 Jun 2017 15:26:35 -0400 X-Google-Sender-Auth: qKfPnwp5avJBBOt1v8DqlSSD29E Message-ID: <CAJowKg+6b5JFgNuFXL0hurPUt15AA3+AGwyFawZQBhgeZAOJDg@mail.gmail.com> To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> Content-Type: multipart/alternative; boundary="089e08229304cab78d0552f60b40" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, 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: Tue, 27 Jun 2017 19:36:55 +0000 Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 27 Jun 2017 19:26:39 -0000 --089e08229304cab78d0552f60b40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There's a pull req to core already for part of it: https://github.com/bitcoin/bitcoin/pull/10444 On Tue, Jun 27, 2017 at 12:31 PM, Jorge Tim=C3=B3n via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > First the implementation, then the technical design (BIP)... will the > analysis come after that? > Will there be any kind of simulations of tje proposed size or will thag > come only after activation on mainnet? > I assume the very last step will be activation on testnet 3 ? > > > On 27 Jun 2017 8:44 am, "Sergio Demian Lerner via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Currently the only implementation that fulfills the requirements of the > NYA agreement is the segwit2x/btc1 implementation, which is being finaliz= ed > this week. > > Segwit2mb does not fulfill the NYA agreement. > > I'm asking now the segwit2x development team when a BIP will be ready so > that Core has the opportunity to evaluate the technical proposal. > > > > > On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Well, this Saturday's "Chinese roundtable" statement from a bunch of >> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the >> coinbase as support for "the New York consensus SegWit2x program btc1 ( >> https://github.com/btc1)", whose code includes the (accelerated >> 336-block) BIP 91 change. So, other facts or interpretations could come= to >> light, but until they do we should probably assume that's what the "NYA" >> (which just broke 80% over the last 24h) means. >> >> >> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark@friedenbach.org= > >> wrote: >> >>> 80% have set "NYA" in their coinbase string. We have no idea what that >>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at >>> the time of the New York agreement, and differs from the actual text >>> of the NYA in substantive ways. The "Segwit2MB" that existed at the >>> time of the NYA, and which was explicitly referenced by the text is >>> the proposal by Sergio Demian Lerner that was made to this mailing >>> list on 31 March. The text of the NYA grants no authority for >>> upgrading this proposal while remaining compliant with the agreement. >>> This is without even considering the fact that in the days after the >>> NYA there was disagreement among those who signed it as to what it >>> meant. >>> >>> I feel it is a very dangerous and unwarranted assumption people are >>> making that what we are seeing now is either 80% support for BIP-91 or >>> for the code in the btc1 repo. >>> >>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik@q32.com> wrote: >>> > # Jacob Eliosoff: >>> > >>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a >>> split. >>> > >>> > Correct. There are 2 short activation periods in BIP91 either of whi= ch >>> > would avoid a split. >>> > >>> > # Gregory Maxwell: >>> > >>> >> unclear to me _exactly_ what it would need to implement to be >>> consistent. >>> > >>> > This is the relevant pull req to core: >>> > >>> > https://github.com/bitcoin/bitcoin/pull/10444 >>> > >>> > Seems OK. It's technically running now on testnet5. I think it (or= a >>> > -bip148 option) should be merged as soon as feasible. >>> > >>> >> previously debunked "XT" and "Classic" hysteria. >>> > >>> > apples vs oranges, imo. segwit is not a contentious feature. the >>> > "bundling" in segwit2x is, but that's not the issue here. the issue >>> is we >>> > are indirectly requiring miners that strongly support segwit to insta= ll >>> > consensus protocol changes outside of bitcoin's standard reference. >>> 80% of >>> > them have signaled they will do so. these are uncharted waters. >>> > >>> > >>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev >>> > <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >> >>> >> I could be wrong, but the latest BIP91 implementation (also included >>> in >>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). >>> (This has >>> >> been updated at >>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So >>> if 80% >>> >> of hashpower is actually running that code and signaling on bit 4 by >>> July 25 >>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before >>> Aug 1, >>> >> and we avoid a split. >>> >> >>> >> There may still be a few non-bit-1 blocks that get orphaned after Au= g >>> 1, >>> >> because they're mined by old BIP141 nodes. But it seems like very f= ew >>> >> miners won't be signaling either Segwit2x *or* BIP141 by then... >>> >> >>> >> Make sense? >>> >> >>> >> >>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach < >>> mark@friedenbach.org> >>> >> wrote: >>> >>> >>> >>> Why do you say activation by August 1st is likely? That would >>> require an >>> >>> entire difficulty adjustment period with >=3D95% bit1 signaling. Th= at >>> seems a >>> >>> tall order to organize in the scant few weeks remaining. >>> >>> >>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev >>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> If segwit is activated before Aug 1, as now seems likely, there wil= l >>> be >>> >>> no split that day. But if activation is via Segwit2x (also likely)= , >>> and at >>> >>> least some nodes do & some don't follow through with the HF 3mo lat= er >>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split - >>> probably in >>> >>> Sep/Oct. How those two chains will match up and how the split will >>> play out >>> >>> is anyone's guess... >>> >>> >>> >>> >>> >>> >>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" >>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> > Ironically, it looks like most of the segwit2x signaling miners a= re >>> >>> > faking it (because they're not signaling segwit which it requires= ). >>> >>> > It'll be unfortunate if some aren't faking it and start orphaning >>> >>> > their own blocks because they are failing to signal segwit. >>> >>> >>> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at >>> the >>> >>> moment, because the segwit2x project is still in alpha-phase >>> according to >>> >>> the timeline. They're just showing commitment. >>> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well a= s >>> >>> actually running a segwit2x node when the time comes. >>> >>> >>> >>> >>> >>> > As far as prevent a chain split goes, all those things >>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- >>> so I >>> >>> > don't think that holds. >>> >>> >>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x >>> (or >>> >>> BIP148) node, because they wouldn't have the new consensus rule of >>> requiring >>> >>> all blocks to signal for segwit. >>> >>> I don't believe there would be any long lasting chainsplit though >>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 >>> blocks if we >>> >>> get unlucky. >>> >>> >>> >>> Hampus >>> >>> >>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev >>> >>> <bitcoin-dev@lists.linuxfoundation.org>: >>> >>>> >>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev >>> >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > Because a large percentage of miners are indifferent, right now >>> miners >>> >>>> > have >>> >>>> > to choose between BIP148 and Segwit2x if they want to activate >>> Segwit. >>> >>>> >>> >>>> Miners can simply continuing signaling segwit, which will leave th= em >>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows >>> >>>> what "segwit2x" is since they keep changing the actual definition >>> and >>> >>>> do not have a specification; but last I saw the near-term behavior >>> the >>> >>>> same as BIP91 but with a radically reduced activation window, so t= he >>> >>>> story would be the same there in the near term). >>> >>>> >>> >>>> Ironically, it looks like most of the segwit2x signaling miners ar= e >>> >>>> faking it (because they're not signaling segwit which it requires)= . >>> >>>> It'll be unfortunate if some aren't faking it and start orphaning >>> >>>> their own blocks because they are failing to signal segwit. >>> >>>> >>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers >>> >>>> could be any more resolute than what we've already seen: >>> >>>> https://en.bitcoin.it/wiki/Segwit_support >>> >>>> >>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev >>> >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > I think it is very na=C3=AFve to assume that any shift would be >>> temporary. >>> >>>> > We have a hard enough time getting miners to proactively upgrade >>> to >>> >>>> > recent versions of the reference bitcoin daemon. If miners >>> interpret >>> >>>> > the situation as being forced to run non-reference software in >>> order >>> >>>> > to prevent a chain split because a lack of support from Bitcoin >>> Core, >>> >>>> > that could be a one-way street. >>> >>>> >>> >>>> I think this is somewhat naive and sounds a lot like the repeat of >>> the >>> >>>> previously debunked "XT" and "Classic" hysteria. >>> >>>> >>> >>>> There is a reason that segwit2x is pretty much unanimously rejecte= d >>> by >>> >>>> the technical community. And just like with XT/Classic/Unlimited >>> >>>> you'll continue to see a strong correlation with people who are >>> >>>> unwilling and unable to keep updating the software at an acceptabl= e >>> >>>> level of quality-- esp. because the very founding on their fork is >>> >>>> predicated on discarding those properties. >>> >>>> >>> >>>> If miners want to go off and create an altcoin-- welp, thats >>> something >>> >>>> they can always do, and nothing about that will force anyone to g= o >>> >>>> along with it. >>> >>>> >>> >>>> As far as prevent a chain split goes, all those things >>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- >>> so I >>> >>>> don't think that holds. >>> >>>> _______________________________________________ >>> >>>> 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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> > >>> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e08229304cab78d0552f60b40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">There's a pull req to core already for part of it:<br>= <br><a href=3D"https://github.com/bitcoin/bitcoin/pull/10444">https://githu= b.com/bitcoin/bitcoin/pull/10444</a><br><br><br><br></div><div class=3D"gma= il_extra"><br><div class=3D"gmail_quote">On Tue, Jun 27, 2017 at 12:31 PM, = Jorge Tim=C3=B3n via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi= tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li= nuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><= div dir=3D"auto"><div>First the implementation, then the technical design (= BIP)... will the analysis come after that?</div><div dir=3D"auto">Will ther= e be any kind of simulations of tje proposed size or will thag come only af= ter activation on mainnet?</div><div dir=3D"auto">I assume the very last st= ep will be activation on testnet 3 ?<div><div class=3D"h5"><br><div class= =3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On 27 Jun 2017= 8:44 am, "Sergio Demian Lerner via bitcoin-dev" <<a href=3D"m= ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@= lists.<wbr>linuxfoundation.org</a>> wrote:<br type=3D"attribution"><bloc= kquote class=3D"m_-8028952536435113512quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Currently the on= ly implementation that fulfills the requirements of the NYA agreement is th= e segwit2x/btc1 implementation, which is being finalized this week.=C2=A0<d= iv><br></div><div>Segwit2mb does not fulfill the NYA agreement.=C2=A0<div><= br></div><div>I'm asking now the segwit2x development team when a BIP w= ill be ready so that Core has the opportunity to evaluate the technical pro= posal.=C2=A0</div><div><br></div><div><br><div><div><br></div></div></div><= /div></div><div class=3D"m_-8028952536435113512elided-text"><div class=3D"g= mail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 21, 2017 at 1:05 AM,= Jacob Eliosoff via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bit= coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin= uxfounda<wbr>tion.org</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"><div dir=3D"ltr">Well, this Saturday's "Chinese roundtable"= ; statement from a bunch of miners=C2=A0(<a href=3D"https://pastebin.com/b3= St9VCF" target=3D"_blank">https://pastebin.com/b<wbr>3St9VCF</a>) says they= intend "NYA" in the coinbase as support for "the New York c= onsensus SegWit2x program btc1 (<a href=3D"https://github.com/btc1" target= =3D"_blank">https://github.com/btc1</a>)", whose code includes the (ac= celerated 336-block) BIP 91 change.=C2=A0 So, other facts or interpretation= s could come to light, but until they do we should probably assume that'= ;s what the "NYA" (which just broke 80% over the last 24h) means.= <div><br></div></div><div class=3D"m_-8028952536435113512m_-643690647297027= 7404HOEnZb"><div class=3D"m_-8028952536435113512m_-6436906472970277404h5"><= div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 20= 17 at 10:11 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:ma= rk@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>></span> w= rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex">80% have set "NYA" in the= ir coinbase string. We have no idea what that<br> means. People are equating it to BIP 91 -- but BIP 91 did not exist at<br> the time of the New York agreement, and differs from the actual text<br> of the NYA in substantive ways. The "Segwit2MB" that existed at t= he<br> time of the NYA, and which was explicitly referenced by the text is<br> the proposal by Sergio Demian Lerner that was made to this mailing<br> list on 31 March. The text of the NYA grants no authority for<br> upgrading this proposal while remaining compliant with the agreement.<br> This is without even considering the fact that in the days after the<br> NYA there was disagreement among those who signed it as to what it<br> meant.<br> <br> I feel it is a very dangerous and unwarranted assumption people are<br> making that what we are seeing now is either 80% support for BIP-91 or<br> for the code in the btc1 repo.<br> <div class=3D"m_-8028952536435113512m_-6436906472970277404m_736866044118352= 0488HOEnZb"><div class=3D"m_-8028952536435113512m_-6436906472970277404m_736= 8660441183520488h5"><br> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <<a href=3D"mailto:erik@q= 32.com" target=3D"_blank">erik@q32.com</a>> wrote:<br> > # Jacob Eliosoff:<br> ><br> >>=C2=A0 will start orphaning non-bit-1 blocks before Aug 1, and we a= void a split.<br> ><br> > Correct.=C2=A0 There are 2 short activation periods in BIP91 either of= which<br> > would avoid a split.<br> ><br> > # Gregory Maxwell:<br> ><br> >> unclear to me _exactly_ what it would need to implement to be cons= istent.<br> ><br> > This is the relevant pull req to core:<br> ><br> > <a href=3D"https://github.com/bitcoin/bitcoin/pull/10444" rel=3D"noref= errer" target=3D"_blank">https://github.com/bitcoin/bit<wbr>coin/pull/10444= </a><br> ><br> > Seems OK.=C2=A0 It's technically running now on testnet5.=C2=A0 = =C2=A0I think it (or a<br> > -bip148 option) should be merged as soon as feasible.<br> ><br> >> previously debunked "XT" and "Classic" hysteri= a.<br> ><br> > apples vs oranges, imo.=C2=A0 =C2=A0segwit is not a contentious featur= e.=C2=A0 =C2=A0the<br> > "bundling" in segwit2x is, but that's not the issue here= .=C2=A0 =C2=A0the issue is we<br> > are indirectly requiring miners that strongly support segwit to instal= l<br> > consensus protocol changes outside of bitcoin's standard reference= .=C2=A0 =C2=A080% of<br> > them have signaled they will do so.=C2=A0 =C2=A0these are uncharted wa= ters.<br> ><br> ><br> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev<br> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= "_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> >><br> >> I could be wrong, but the latest BIP91 implementation (also includ= ed in<br> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days).=C2= =A0 (This has<br> >> been updated at<br> >> <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.me= diawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bi= p<wbr>s/blob/master/bip-0091.mediawi<wbr>ki</a>.)=C2=A0 So if 80%<br> >> of hashpower is actually running that code and signaling on bit 4 = by July 25<br> >> or so, then those 80+% will start orphaning non-bit-1 blocks befor= e Aug 1,<br> >> and we avoid a split.<br> >><br> >> There may still be a few non-bit-1 blocks that get orphaned after = Aug 1,<br> >> because they're mined by old BIP141 nodes.=C2=A0 But it seems = like very few<br> >> miners won't be signaling either Segwit2x *or* BIP141 by then.= ..<br> >><br> >> Make sense?<br> >><br> >><br> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <<a href=3D"m= ailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>><= br> >> wrote:<br> >>><br> >>> Why do you say activation by August 1st is likely? That would = require an<br> >>> entire difficulty adjustment period with >=3D95% bit1 signa= ling. That seems a<br> >>> tall order to organize in the scant few weeks remaining.<br> >>><br> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev<br= > >>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<= br> >>><br> >>> If segwit is activated before Aug 1, as now seems likely, ther= e will be<br> >>> no split that day.=C2=A0 But if activation is via Segwit2x (al= so likely), and at<br> >>> least some nodes do & some don't follow through with t= he HF 3mo later<br> >>> (again, likely), agreed w/ Greg that *then* we'll see a sp= lit - probably in<br> >>> Sep/Oct.=C2=A0 How those two chains will match up and how the = split will play out<br> >>> is anyone's guess...<br> >>><br> >>><br> >>><br> >>> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin= -dev"<br> >>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<= br> >>><br> >>> > Ironically, it looks like most of the segwit2x signaling = miners are<br> >>> > faking it (because they're not signaling segwit which= it requires).<br> >>> > It'll be unfortunate if some aren't faking it and= start orphaning<br> >>> > their own blocks because they are failing to signal segwi= t.<br> >>><br> >>> Well, they're doing some kind of "pre-signaling"= in the coinbase at the<br> >>> moment, because the segwit2x project is still in alpha-phase a= ccording to<br> >>> the timeline. They're just showing commitment.<br> >>> I'm sure they will begin signaling on version bit 4/BIP91 = as well as<br> >>> actually running a segwit2x node when the time comes.<br> >>><br> >>><br> >>> > As far as prevent a chain split goes, all those things<br= > >>> > (148/91/segwit2x(per today)) effectively guarantee a chai= nsplit-- so I<br> >>> > don't think that holds.<br> >>><br> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Seg= wit2x (or<br> >>> BIP148) node, because they wouldn't have the new consensus= rule of requiring<br> >>> all blocks to signal for segwit.<br> >>> I don't believe there would be any long lasting chainsplit= though<br> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-= 3 blocks if we<br> >>> get unlucky.<br> >>><br> >>> Hampus<br> >>><br> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev<br> >>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>>:<br> >>>><br> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin= -dev<br> >>>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wro= te:<br> >>>> > Because a large percentage of miners are indifferent,= right now miners<br> >>>> > have<br> >>>> > to choose between BIP148 and Segwit2x if they want to= activate Segwit.<br> >>>><br> >>>> Miners can simply continuing signaling segwit, which will = leave them<br> >>>> at least soft-fork compatible with BIP148 and BIP91 (and g= od knows<br> >>>> what "segwit2x" is since they keep changing the = actual definition and<br> >>>> do not have a specification; but last I saw the near-term = behavior the<br> >>>> same as BIP91 but with a radically reduced activation wind= ow, so the<br> >>>> story would be the same there in the near term).<br> >>>><br> >>>> Ironically, it looks like most of the segwit2x signaling m= iners are<br> >>>> faking it (because they're not signaling segwit which = it requires).<br> >>>> It'll be unfortunate if some aren't faking it and = start orphaning<br> >>>> their own blocks because they are failing to signal segwit= .<br> >>>><br> >>>> I don't think the rejection of segwit2x from Bitcoin&#= 39;s developers<br> >>>> could be any more resolute than what we've already see= n:<br> >>>> <a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel= =3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_su= pport</a><br> >>>><br> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitc= oin-dev<br> >>>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wro= te:<br> >>>> > I think it is very na=C3=AFve to assume that any shif= t would be temporary.<br> >>>> > We have a hard enough time getting miners to proactiv= ely upgrade to<br> >>>> > recent versions of the reference bitcoin daemon. If m= iners interpret<br> >>>> > the situation as being forced to run non-reference so= ftware in order<br> >>>> > to prevent a chain split because a lack of support fr= om Bitcoin Core,<br> >>>> > that could be a one-way street.<br> >>>><br> >>>> I think this is somewhat naive and sounds a lot like the r= epeat of the<br> >>>> previously debunked "XT" and "Classic"= hysteria.<br> >>>><br> >>>> There is a reason that segwit2x is pretty much unanimously= rejected by<br> >>>> the technical community.=C2=A0 And just like with XT/Class= ic/Unlimited<br> >>>> you'll continue to see a strong correlation with peopl= e who are<br> >>>> unwilling and unable to keep updating the software at an a= cceptable<br> >>>> level of quality-- esp. because the very founding on their= fork is<br> >>>> predicated on discarding those properties.<br> >>>><br> >>>> If miners want to go off and create an altcoin-- welp, tha= ts something<br> >>>> they can always do,=C2=A0 and nothing about that will forc= e anyone to go<br> >>>> along with it.<br> >>>><br> >>>> As far as prevent a chain split goes, all those things<br> >>>> (148/91/segwit2x(per today)) effectively guarantee a chain= split-- so I<br> >>>> don't think that holds.<br> >>>> ______________________________<wbr>_________________<br> >>>> bitcoin-dev mailing list<br> >>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= arget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> >>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listi= nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo= undation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> >>><br> >>><br> >>><br> >>> ______________________________<wbr>_________________<br> >>> bitcoin-dev mailing list<br> >>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> >>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/= bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda= tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> >>><br> >>><br> >>> ______________________________<wbr>_________________<br> >>> bitcoin-dev mailing list<br> >>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> >>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/= bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda= tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> >><br> >><br> >><br> >> ______________________________<wbr>_________________<br> >> bitcoin-dev mailing list<br> >> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= "_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> >> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc= oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation= .<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> >><br> ><br> </div></div></blockquote></div><br></div> </div></div><br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= /mailman/listinfo/bitcoin-d<wbr>ev</a><br> <br></blockquote></div><br></div> </div><br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= /mailman/listinfo/bitcoin-d<wbr>ev</a><br> <br></blockquote></div><br></div></div></div></div></div> <br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= <wbr>linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= /mailman/listinfo/bitcoin-<wbr>dev</a><br> <br></blockquote></div><br></div> --089e08229304cab78d0552f60b40--