Add incompatible modification to block header, new P2P network and 2 way replay protection

You recently tweeted this:

It is GREAT for free market and competition that users can easily jump between ETH / ETC, BTC / BCC, BTC / LTC #interoperability #open

Source: https://twitter.com/jgarzik/status/893133969314721793

I agree with this comment. I think it is great that Bitcoin Cash (BCH) launched and we have free market competition. However, in order for this free market competition to work well, we need to make the launch of this SegWit2x coin as smooth as possible, such that users and investors "can easily jump" between BTC and the new coin, which I am sure you want. Right now, it appears as if SegWit2x is constructed in such a way that will not enable this easy jumping.

What BCH did well and what SegWit2x should copy:

1. Two way replay protection, enabled by default, such that transactions on one chain are invalid on the other chain.

BCH implemented this and it seemed to work well. It enables users and investors to "easily jump" from one chain to another, just like you want. As you can imagine, not implementing this could cause total chaos for users and businesses, as well as massive amounts of congestion on both chains as many users keep trying and possibly failing to split their coins. As I explained here https://medium.com/@jonny1000/the-potential-economic-and-financial-market-implications-of-a-contentious-hardfork-d54cf1d124e6, SegWit2x supporters are likely to be wanting to run clients following the original chain, and vica versa.

Not only is replay protection absolutely necessary, it has also been demanded by many exchanges and businesses in the economy. These businesses have stated that they will not support a coin that does not implement this, which will likely make this SegWit2x project a failure and not allow an easy jump from one chain to another, like you want.

Here is a summary of some comments on this matter from businesses:

Bitfinex/Bitstamp/Bittrex/BTCC/Kraken/ShapeShift + others

we insist that the Bitcoin Unlimited community (or any other consensus breaking implementation) build in strong two-way replay protection

Source: https://www.bitfinex.com/bitcoin_hardfork_statement

Poloniex

At a minimum, any new fork must include built-in replay protection

Source: https://poloniex.com/press-releases/2017.03.17-Hard-Fork/

BitGo

The hard fork must provide strong 2-way replay protection. This means that transactions valid on one chain should be invalid on the other

Source: https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-fork-71e572506d7d

BitMEX

Strong two-way replay protection, enabled by default, such that transactions on each chain are invalid on the other chain.

Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/

I kindly ask that you please listen to these businesses, for what is a very reasonable request. Some of these businesses even signed the NYA (https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77), therefore, since that agreement is the basis for this client, the software should be consistent with what they have demanded, otherwise they will be unable to follow the NYA.

2. A modification to the block header, such that all wallets need to upgrade to follow the new chain.

The BCH coin had a downward adjustment to the difficulty, making the block header incompatible with Bitcoin. This is a good thing, as it means existing wallets wont accidentally follow the new BCH coin.

Imagine if it did not have this feature. If BCH took the lead and became the most work chain, wallets could follow this chain, yet their transactions would be invalid on that chain and valid on the less work chain. Why would anyone want that? That would not enable the easy jumping between the two coins, like I still think you want.

In addition to this, businesses have started demanding this:

BitMEX

A modification to the block header such that all wallets (including light clients) are required to upgrade to follow the new chain.

Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/

What BCH did poorly and where SegWit2x can improve:

3. Build and use a new P2P network before the new coin launches

I was running the Bitcoin-ABC client before and after the recent chainsplit. Before the chainsplit occurred I was connected exclusively to many Bitcoin Core peers and was worried about what would happen after the split. Then when the chainsplit happened my Bitcoin-ABC node kept cycling through hundreds of Bitcoin Core peers and banning them. I was struggling to find good peers for days. The wallet was very difficult to use, it was often many blocks behind what people were telling me on internet chat forums and many of my transactions took a long time to propagate and I had to re-broadcast some of them hundreds of times for them to work.

The P2P network for SegWit2x should be built BEFORE the chainsplit. I do not understand what you want to happen without doing this? Are you expecting all nodes to be connected to each other, then in one instant when the chainsplit occurs, for two separate p2p networks to magically form? Why not be prudent and build the network beforehand?

Since nodes need to upgrade for SegWit2x anyway, why not build the new network magic before the chainsplit occurs, that way it can be far smoother than somehow expecting it to happen instantly.

If this does not happen, users may struggle to make transactions, and jump between the two coins like we all want.

Two way replay protection is nice and needed, but only by coins forking with a minority of hash rate.

S2X fork will happen only with a (super)majority of hash rate, so the legacy, slow and mor eexpensive chain will need to add replay protection to not alienate its users even more.

Please open this bug report on the projects not accepting S2X fork, thanks.

S2X fork will happen only with a (super)majority of hash rate

False, it will happen 3 months after segwit activates - unconditionally of what the hashrate does.

@kek-coin indeed it will happen unconditionally but we already know that there is 80%+ of miners that supports it so @Pheromon is not wrong at all.

@NiKiZe what @Pheromon said is that it will happen only with a (super)majority of hashrate - this is provably false. It will happen, regardless of how much hashrate pulls out. If the "only" is removed from that sentence it turns into a prediction, not an assertion, which people are free to form their own opinion about, but as it stands it is simply untrue.

@kek-coin The 2X fork starts when the first block between 1MB and 2MB is generated. btc1 miners accept such a block as valid, and continue mining on top of it. If a longer chain orphans this block, btc1 miners will switch to mining on that longer chain, even if it is only composed of blocks that are no larger that 1MB. SegWit2X is not a coin, it is Bitcoin. The perception that this project is intending to start an forked altcoin is incorrect.

@XenoG here you are wrong the Segwit2x chain REQUIRES a block with size >1MB at 90*144 blocks after segwit activation. see b368c9b

@NiKiZe sorry! My mistake. Would you mind posting a link the code that does that for the record? I would like to take a look. I am trying to find it myself.

And this is the code chunk:

bitcoin/src/validation.cpp

Lines 3106 to 3109 in b368c9b

    
           if (fBIP102FirstBlock) { 
        
               if (::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) <= MAX_LEGACY_BLOCK_SIZE) 
        
                   return state.DoS(100, false, REJECT_INVALID, "bad-blk-length-toosmall", false, "size limits failed"); 
        
           }

I was very mistaken. I was under the impression that it wasn't mandatory. I'm glad it is.

	if (fBIP102FirstBlock) {
	if (::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION \| SERIALIZE_TRANSACTION_NO_WITNESS) <= MAX_LEGACY_BLOCK_SIZE)
	return state.DoS(100, false, REJECT_INVALID, "bad-blk-length-toosmall", false, "size limits failed");
	}