> 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