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)

[JaredR26]

@jli225

Glad to know that you realized the current Core Committee is ill-advised and unethical and it became an echo chamber after everyone who disagreed with you gave up and quit.

You were caught slandering Satoshi, Gavin and Mike Hearn regularly in chats among Core Committee members.

Come on dude, stop it. My comment was probably over the line as a response to Maxwell's direct statements, and for that I apologize to all. But yours is clearly over the line into personal attacks. We are and need to be better than this here. I won't respond any further here unless there's something technical to add or raise, as it should be.

[jli225]

@JaredR26 Thank you, edited.

[nukebloodaxe]

This would, effectively, be a modification of BIP 91. I would suggest allowing the BIP 91 soft fork to occur as intended, which would then allow adequate preparation and testing of code for the hard fork 3 months later.

If there is a problem following BIP 91 activation, then the remainder of the network (all implementations) will be able to continue functioning until a fix. I would not be comfortable relying on all other implementations being ready if a change were made to the signalling method now.

The 3 month period following BIP91 activation exists as a safety measure so that individuals, companies and other implementations can sort themselves out. Removing the safety period would not be wise in my opinion, as this would only exacerbate problems (there will be problems, I assure you,) and effectively make BIP 91 a hard fork instead of a soft fork; for other implementations especially.

[jli225]

@earonesty Could you give any technical reason that we have to extend the hard fork timeline? It seems that you only kept blaming this project everywhere yet never provided any constructive technical explanation.

You are also a supporter of notorious BIP148 which contradicts to everything Bitcoin stands for. However, you never mentioned any doubt such as "short time - coercion - rush - twist - chain split". In case you did not know, double standard will impair one's credibility drastically. To be honest, your political attitude is an offense to all Bitcoin has achieved because due to it's the strong foundations.

We certainly can extend it if necessary. But Now that you and other small blockers haven't been able to find any reasonable explanation, it only proves that we can do the hard fork successfully and graciously.

Increasing the blocklimit was a consensus from the beginning. The "coercion" to block it without another consensus is mired in a misinterpretation of Bitcoin Paper and sets a precedent for Bitcoin that may undermine the value prospect of all cryptocurrency in general.

The era of Core Committee has gone over. Even staying as a Core Committee member could be considered irresponsible. Gladly the most respected and reliable devs have left one after another. I think the best you can hope for the Core Committee is for it to be quietly ignored.

[jgarzik]

Proposing to close before release.

I took this to the mailing list + left the issue open a long time, to give the idea a reasonably airing. It sounds like this could create additional chain disruption + community contention, versus the most likely path of 2M HF adoption lock-in anyway.