(That is: "...because they're mined by old non-Segwit2x nodes that *aren't signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)
On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff <jacob.elios...@gmail.com> 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 <m...@friedenbach.org> > 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 < >> bitcoin-dev@lists.linuxfoundation.org> 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" < >> bitcoin-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 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 < >> 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 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 >>> <bitcoin-dev@lists.linuxfoundation.org> 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
