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 is > 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 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 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 >=95% 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öberg 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 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 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-- 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 > >>> : > >>>> > >>>> 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 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 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ïve 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 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 something > >>>> 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 > >> > > >