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
