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 9324A412 for ; Wed, 21 Jun 2017 04:05:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A209E1FB for ; Wed, 21 Jun 2017 04:05:55 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id m77so85966781lfe.0 for ; Tue, 20 Jun 2017 21:05:55 -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=QVbnMWx8V3frvFBt32Z294Ur6mZ8UQ93wCp2XXNC1DM=; b=uLOQl08o7UFpLgwECAY3bWNNLERKzlPGUmfAjnaNXdrIKZHfszyPmR/q2fcMbBN0jZ tn4QMNq9C7NBjtjTJD+H5BijTq/n0F4mbuszfQorpj14OCfYsZsncGxGJA2mc5k1Cchi 3DKWEV3Y1vVid5FUFDI8AkmBTR5QrWVHutMwdz/EXAjiWHLHScuA09/Q3I8OS2P2oBPJ lzdFzjbfNHQ63hIZj/Tfvp+9XgMxDtoTwpSC6ND1lUjL5M0dpvcdahBETPWuAraPOe7U havURdTlX+w3bZA7SS0CGFiLpWkeVXu72UHTPxlkzEhM5Wm7B6rnNUZkX7Wg2n3x2sPG 3vuQ== 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=QVbnMWx8V3frvFBt32Z294Ur6mZ8UQ93wCp2XXNC1DM=; b=UMvGpwXVC7BtOIwwL3BJwy4dRFvTzO9TviLUrw5qSdHcg58MRouS/3PSg7+8OqZF6B +cCooMxIM3vFXuQ6sfbUBAibY949hhS/GlzY39RDepLtZlGR5D+t8bwTW7lY43fNtvmE Iz5TxGMWQOpzc9Xa+SPoRkXDFJu3dM3Hz4iV3IeiuEaumSo4/rxWE5FRNQInZwde9iQC 7nP0bj+W9akz+3X6ufWxOqpKViPYZXZEG7xJk0vYF9J4FpViWrHuqPkat9jRmzBLZiSf XybYvQogllgUczFggueg/b0exW0kiRe7OzFhQntqfIqf335eEAJCk06k39rS83zxNSop Bs6Q== X-Gm-Message-State: AKS2vOy0bg1Ado7IQ0axO8BVkRfgQAk2osKGrYtRtL3ucUHeWtu6FoP0 0tM48QmS8m+I3Hik77JPat6dXAvfIg== X-Received: by 10.46.69.130 with SMTP id s124mr9148174lja.90.1498017953944; Tue, 20 Jun 2017 21:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 21:05:53 -0700 (PDT) In-Reply-To: References: From: Jacob Eliosoff Date: Wed, 21 Jun 2017 00:05:53 -0400 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary="001a114b0ef6031af80552707c81" 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: Wed, 21 Jun 2017 10:40:12 +0000 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 04:05:57 -0000 --001a114b0ef6031af80552707c81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 which > > 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 i= s > we > > are indirectly requiring miners that strongly support segwit to install > > 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 > > wrote: > >> > >> I could be wrong, but the latest BIP91 implementation (also included i= n > >> 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 Au= g > 1, > >> and we avoid a split. > >> > >> There may still be a few non-bit-1 blocks that get orphaned after Aug = 1, > >> because they're mined by old BIP141 nodes. But it seems like very few > >> miners won't be signaling either Segwit2x *or* BIP141 by then... > >> > >> Make sense? > >> > >> > >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach > > >> wrote: > >>> > >>> Why do you say activation by August 1st is likely? That would require > an > >>> entire difficulty adjustment period with >=3D95% bit1 signaling. That > 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 > >>> wrote: > >>> > >>> If segwit is activated before Aug 1, as now seems likely, there will = 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 later > >>> (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" > >>> wrote: > >>> > >>> > Ironically, it looks like most of the segwit2x signaling miners are > >>> > 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 t= he > >>> moment, because the segwit2x project is still in alpha-phase accordin= g > to > >>> the timeline. They're just showing commitment. > >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as > >>> 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-- s= o > 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 block= s > if we > >>> get unlucky. > >>> > >>> Hampus > >>> > >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev > >>> : > >>>> > >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev > >>>> 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 them > >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows > >>>> what "segwit2x" is since they keep changing the actual definition an= d > >>>> do not have a specification; but last I saw the near-term behavior t= he > >>>> same as BIP91 but with a radically reduced activation window, so the > >>>> story would be the same there in the near term). > >>>> > >>>> Ironically, it looks like most of the segwit2x signaling miners are > >>>> 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 > >>>> 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 t= o > >>>> > recent versions of the reference bitcoin daemon. If miners interpr= et > >>>> > the situation as being forced to run non-reference software in ord= er > >>>> > 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 t= he > >>>> previously debunked "XT" and "Classic" hysteria. > >>>> > >>>> There is a reason that segwit2x is pretty much unanimously rejected = 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 acceptable > >>>> 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 somethi= ng > >>>> they can always do, and nothing about that will force anyone to go > >>>> 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 > >> > > > --001a114b0ef6031af80552707c81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, this Saturday's "Chinese roundtable" s= tatement from a bunch of miners=C2=A0(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.=C2=A0 So,= other facts or interpretations could come to light, but until they do we s= hould 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 Fr= iedenbach <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 t= he
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:
>
>>=C2=A0 will start orphaning non-bit-1 blocks before Aug 1, and we a= void a split.
>
> Correct.=C2=A0 There are 2 short activation periods in BIP91 either of= which
> would avoid a split.
>
> # Gregory Maxwell:
>
>> unclear to me _exactly_ what it would need to implement to be cons= istent.
>
> This is the relevant pull req to core:
>
> https://github.com/bitcoin/bitcoin/pull/10444=
>
> Seems OK.=C2=A0 It's technically running now on testnet5.=C2=A0 = =C2=A0I think it (or a
> -bip148 option) should be merged as soon as feasible.
>
>> previously debunked "XT" and "Classic" hysteri= a.
>
> apples vs oranges, imo.=C2=A0 =C2=A0segwit is not a contentious featur= e.=C2=A0 =C2=A0the
> "bundling" in segwit2x is, but that's not the issue here= .=C2=A0 =C2=A0the issue is we
> are indirectly requiring miners that strongly support segwit to instal= l
> consensus protocol changes outside of bitcoin's standard reference= .=C2=A0 =C2=A080% of
> them have signaled they will do so.=C2=A0 =C2=A0these are uncharted wa= ters.
>
>
> On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>>
>> I could be wrong, but the latest BIP91 implementation (also includ= ed in
>> Segwit2x) cuts the activation period to 336 blocks (2.33 days).=C2= =A0 (This has
>> been updated at
>> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.)=C2=A0 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 befor= e Aug 1,
>> and we avoid a split.
>>
>> There may still be a few non-bit-1 blocks that get orphaned after = Aug 1,
>> because they're mined by old BIP141 nodes.=C2=A0 But it seems = like very few
>> 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 signa= ling. That 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 >>> <b= itcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> If segwit is activated before Aug 1, as now seems likely, ther= e will be
>>> no split that day.=C2=A0 But if activation is via Segwit2x (al= so likely), and at
>>> least some nodes do & some don't follow through with t= he HF 3mo later
>>> (again, likely), agreed w/ Greg that *then* we'll see a sp= lit - probably in
>>> Sep/Oct.=C2=A0 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"
>>> <b= itcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> > Ironically, it looks like most of the segwit2x signaling = miners are
>>> > 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 segwi= t.
>>>
>>> Well, they're doing some kind of "pre-signaling"= in the coinbase at the
>>> moment, because the segwit2x project is still in alpha-phase a= ccording to
>>> the timeline. They're just showing commitment.
>>> I'm sure they will begin signaling on version bit 4/BIP91 = as well as
>>> 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 chai= nsplit-- so I
>>> > don't think that holds.
>>>
>>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Seg= wit2x (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
>>> <b= itcoin-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 them
>>>> at least soft-fork compatible with BIP148 and BIP91 (and g= od 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 wind= ow, so the
>>>> story would be the same there in the near term).
>>>>
>>>> Ironically, it looks like most of the segwit2x signaling m= iners are
>>>> 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&#= 39;s developers
>>>> could be any more resolute than what we've already see= n:
>>>> https://en.bitcoin.it/wiki/Segwit_su= pport
>>>>
>>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitc= oin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> > I think it is very na=C3=AFve to assume that any shif= t would be temporary.
>>>> > We have a hard enough time getting miners to proactiv= ely upgrade to
>>>> > recent versions of the reference bitcoin daemon. If m= iners interpret
>>>> > the situation as being forced to run non-reference so= ftware in order
>>>> > to prevent a chain split because a lack of support fr= om Bitcoin Core,
>>>> > that could be a one-way street.
>>>>
>>>> I think this is somewhat naive and sounds a lot like the r= epeat of the
>>>> previously debunked "XT" and "Classic"= hysteria.
>>>>
>>>> There is a reason that segwit2x is pretty much unanimously= rejected by
>>>> the technical community.=C2=A0 And just like with XT/Class= ic/Unlimited
>>>> you'll continue to see a strong correlation with peopl= e who are
>>>> unwilling and unable to keep updating the software at an a= cceptable
>>>> 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, tha= ts something
>>>> they can always do,=C2=A0 and nothing about that will forc= e anyone to go
>>>> along with it.
>>>>
>>>> As far as prevent a chain split goes, all those things
>>>> (148/91/segwit2x(per today)) effectively guarantee a chain= split-- so I
>>>> don't think that holds.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> b= itcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfo= undation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitco= in-dev@lists.linuxfoundation.org
>>> https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitco= in-dev@lists.linuxfoundation.org
>>> https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>

--001a114b0ef6031af80552707c81--