The stated reason for this revert was that Peter Todd and David Harding had found that the replay protection could be used to break lightning and other similar smart contracts by using the blacklist address employed in the replay protection to make an un-spendable payment in the smart contract.

This leaves bitcoin2x with no replay protection as of now, and only 1 month until the planned fork date. Although it is not guaranteed, I would think this would cause exchanges to reconsider their support since they no longer have a surefire method of splitting coins, and therefore could be open to replay attacks costing them millions.

Some exchanges intend to list BTU and all of us will try to take steps to preserve and enable access to customers' BTU. However, none of the undersigned can list BTU unless we can run both chains independently without incident. Consequently, we insist that the Bitcoin Unlimited community (or any other consensus breaking implementation) build in strong two-way replay protection. Failure to do so will impede our ability to preserve BTU for customers and will either delay or outright preclude the listing of BTU.

After committing to this key safety feature, of strong to way replay protection, he has now backed out of the agreement. Erik now supports 2x, which does not include strong replay two-way replay protection. Erik then tried to twist the meaning of words saying 2x was not "consensus breaking", since it has consensus. This is clearly not what the commitment means, it uses the words consensus to mean consensus rules, not "community consensus". Besides, there is not community consensus for 2x anyway, saying so is arrogant.

Erik cannot face up to the truth, so decided to block me on Twitter instead.

I originally thought it would be relatively simple to add replay attack protection (change something about how the tx hash is generated) in the event of a fork. But the BU folks mentioned that this would break SPV clients (including many mobile wallets). So it is not free to do that way, although still an option.

One solution we brainstormed, was using some coins that were only valid on one chain (for example newly mined coins) and adding 1 satoshi of “taint” to all generated transactions. This would work but is not perfect. For instance, newly mined coins can’t be spent for 100 blocks, so at a minimum it would cause economic nodes to have a delay in the event of a hard fork. It is also non-trivial for all wallet software to implement this (fair amount of work, especially at scale). There is also an operational challenge that you would have to rush to get these newly mined coins while the hard fork was happening, so you could not prepare in advance. It would be a messy for sure.

Another option would be to try and double spend some coins across the forked chains (get a transaction with some coins going to two different addresses mined across the two chains). These coins could then also be used for “taint”, but you wouldn’t have to wait the full 100 blocks. This is a little bit better, but still not perfect.

I suspect there is a better solution though. What are people’s thoughts?