BIP91 activation does not orphan non bit-4 blocks

[tomasvdw]

I have noticed that on activation of BIP91 non-bit 1 blocks are rejected but non-bit 4 blocks are not.

It would be much safer to also reject non-bit 4 signaling blocks as customary with earlier softforks, because

• This removes the risk of the hardfork causing a chainsplit (unless miners would run a new implementation which maliciously reuses bit 4 as SegWit-only)
• By extension, this removes the need for replay protection
• It eliminates the inconsistency that only non-SegWit miners are forced to upgrade.

I understand the benefit of compatibility with existing non-mining nodes through BIP91, but attempting compatibility with (some) miners seems to have more drawbacks than benefits as it increases the risks of the hardfork.

(Note if this is accepted and hands are short I can do a PR for this)

[jameshilliard]

I have noticed that on activation of BIP91 non-bit 1 blocks are rejected but non-bit 4 blocks are not.

Mandatory bit1 signalling is only temporary until segwit is locked in. Miners already will have to upgrade otherwise they risk building on top of invalid blocks.

It would be much safer to also reject non-bit 4 signaling blocks as customary with earlier softforks

This would increase disruption during mandatory signalling as there would be potentially more orphans, this would not likely be an issue for larger pools but for smaller miners that aren't keeping up with recent changes.

This removes the risk of the hardfork causing a chainsplit (unless miners would run a new implementation which maliciously reuses bit 4 as SegWit-only)

It's trivial for any miner to false signal, in fact many effectively already do since they hard code version bits in their stratum servers.

By extension, this removes the need for replay protection

It does not since we've already established that it's impossible to prevent false signalling.

It eliminates the inconsistency that only non-SegWit miners are forced to upgrade.

Maintaining backwards compatibility as much as possible and minimizing disruption should be a goal.

attempting compatibility with (some) miners seems to have more drawbacks than benefits as it increases the risks of the hardfork

It does not, and it would have been preferable if we could avoid a mandatory signalling period, unfortunately there's just no realistic technical way we could do that at 80% hashpower without waiting for the existing segwit deployment to expire.

[tomasvdw]

This would increase disruption during mandatory signalling as there would be potentially more orphans, this would not likely be an issue for larger pools but for smaller miners that aren't keeping up with recent changes.

Well, the 40% non-Core miners will also have to upgrade and otherwise also increase orphan rate. Why would this not be a problem for them, but would it be a problem for the 30% SegWit-only miners?

It's trivial for any miner to false signal, in fact many effectively already do since they hard code version bits in their stratum servers.

There is quite a difference between a chainsplit because some miners did not upgrade, or a chainsplit caused by maliciously (and openly) false flagging bit 4 without actually following the SegWit2X specification

The first is likely, the latter is not really realistic due to its destructive nature. Why would miners want to cause such damage?

[jameshilliard]

There is quite a difference between a chainsplit because some miners did not upgrade, or a chainsplit caused by maliciously false flagging bit 4 without actually following the SegWit2X specification

You're intentionally trying to make a HF coercive, that's the complete wrong approach as it would only encourage false signalling.

The first is likely, the latter is not really realistic due to its destructive nature. Why would miners would want to cause such damage?

You're looking at this all completely wrong, the HF should be done cleanly and in a way that minimizes disruption as much as possible. The hard fork should be something users will want to upgrade to because it improves things, it should not be something they are forced into, by design bitcoin is highly resistant to coercive tactics like that.

[kek-coin]

@tomasvdw there is absolutely no point to signalling bit4 after BIP91 locks in.

1. BIP9 was intentionally designed to let version bits be reused; forcing them to stay occupied completely messes up that mechanism. Is there any rationale behind this?

2. It does not help S2X in any way; the hardfork activation logic - as far as I am aware - goes something along the lines of "IFF segwit has been active for 3 months -> hardfork". Doesn't even require bit4 signalling to have reached 80% ever.

3. Fake-signalling bit4 is trivially easy. You are not forcing anyone to upgrade this way.

Why would miners want to cause such damage?

Are you forgetting that they already have done exactly this in the past?

[tomasvdw]

You're intentionally trying to make a HF coercive, that's the complete wrong approach as it would only encourage false signaling.

Of course. Any softfork is coercive for the minority miners, but we want to make SegWit2X coercive; not just SegWit. Coercion (by risking losses) of the minority is why we have a functional consensus system.

IMO false signaling is a red herring. Bit signaling is not just technical, and a miner that would signal a bit defined as spec X, but have his node behaves as spec Y would be very destructive. No miner would benefit from such destructive behavior, as miners benefit from seeking consensus
.

BIP9 was intentionally designed to let version bits be reused;

You can just enforce signaling until the hardfork.

It does not help S2X in any way; the hardfork activation logic - as far as I am aware - goes something along the lines of "IFF segwit has been active for 3 months -> hardfork". Doesn't even require bit4 signalling to have reached 80% ever.

It does help S2X as it prevents a chain split. Why would anyone be against that?

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

From the first commits by Jeff Garzik, we've seen changes that accommodate non upgrading BIP141 nodes (with BIP91), and non upgrading BIP148 nodes (with the fast activation). But if we want SegWit2X to be successful we should instead encourage upgrading, especially for miners.

Frankly, I get the impression that @jameshilliard and @kek-coin, you are both primarily aiming at SegWit activation, not the success of SegWit2X.

[jameshilliard]

Any softfork is coercive for the minority miners, but we want to make SegWit2X coercive; not just SegWit.

The goal is to minimize coerciveness of soft forks as much as is technically possible. Soft fork features in general are designed to be as optional as realistically possible for both users and miners, we do sometimes have to make trade-offs however for technical reasons. BIP91 only has a mandatory signalling period because there's not a technical way to lower the activation threshold unless we wait for the existing segwit deployment to expire. If we could lower the segwit activation threshold without a mandatory signalling period we would have done that instead.

IMO false signaling is a red herring. Bit signaling is not just technical, and a miner that would signal a bit defined as spec X, but have his node behaves as spec Y would be very destructive. No miner would benefit from such destructive behavior, as miners benefit from seeking consensus

Lets assume there are some miners that are not wanting/intending to follow the HF, if forced to signal bit4 they now have no other option than to false signal because otherwise their blocks will be orphaned. This behavior wouldn't be considered destructive, it would just them considered protecting themselves. If signalling is optional then it is much more likely the miner will signal accurately.

It does help S2X as it prevents a chain split. Why would anyone be against that?

Because it doesn't at all, it gives a false sense of security and very likely would make things worse as any miners that intend to reject the HF would be forced to false signal.

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

The mandatory signalling is only there at all because there are no other realistic technical options.

But if we want SegWit2X to be successful we should instead encourage upgrading, especially for miners.

We should avoid being coercive as much as possible and instead try and make the fork as desirable as possible. Use the carrot not the stick.

[drunkenclam]

Why would we require the ~70% non-segwit miners to upgrade but the ~30% segwit miners not, if this so clearly increases the risks of a chain split?

If there are >0% miners NOT signalling bit 4 or bit 1, BIP141 Segwit miners risk building blocks on those not signalling blocks, while the majority of miners is orphaning those blocks. Segwit miners have to upgrade as well, or at least use a Segwit2x or BIP148 border node.

[jameshilliard]

Segwit miners have to upgrade as well, or at least use a Segwit2x or BIP148 border node.

A BIP148 border node would not be enough as it doesn't contain BIP91.

[tomasvdw]

@jameshilliard I believe that the risk of some <20% splitting the chain with false flagging is much smaller than <20% splitting the chain by not updating their software.

But I guess our difference here is more ideological than technical.

I will leave this open for the segwit2x team to either close or adopt.

[jameshilliard]

I believe that the risk of some <20% splitting the chain with false flagging is much smaller than <20% splitting the chain by not updating their software.

Clearly the best solution would be to decouple BIP91 activation from the HF as I've recommend, making BIP91 activation coupled was clearly a political decision that makes it harder to determine actual support for the HF by itself.

[tomasvdw]

I don't understand what you are saying. There is already a proposal for SegWit decoupled from the HF. It has only 30% mining support. How is that the best solution?

This issue and repository is about SegWit2X, which is SegWit and a 2mb HF.

[jameshilliard]

There is already a proposal for SegWit decoupled from the HF.

I'm saying there should be separate activation for BIP91 and for the HF, because the decisions will be separate no matter what.

It has only 30% mining support.

It's much higher than that, it was just being used as a bargaining chip.

How is that the best solution?

Because the decisions are inherently decoupled regardless of if you use the same activation bit or not. Hard fork activation simply does not work the same way as soft fork activation does technically.

[Pheromon]

I agree: Core is now quiet because btc1 will allow them to have segwit enabled even with their client, and that's all they want.
After that, they will start to complain about the HF and take every chance of ruining it: they don't want to increase the block size, ever.
And they will succed this time too.
You'll see.

[jameshilliard]

I agree: Core is now quiet because btc1 will allow them to have segwit enabled even with their client, and that's all they want.

Core has been pretty much universally opposed to segwit2x publicly https://en.bitcoin.it/wiki/Segwit_support so clearly they aren't being quiet.

[kek-coin]

Frankly, I get the impression that @jameshilliard and @kek-coin, you are both primarily aiming at SegWit activation, not the success of SegWit2X.

No, I am pointing out that your proposal doesn't actually help with anything. The only measurable difference it would make is add more crud to the code making the code review stage that much harder. Bloating the diff will only serve to make this project's code less attractive and therefore make S2X success chance lower.