Replay-protection against BCash

[cryptomeow]

Unfortunately when BitcoinABC implemented the Nov13th hardfork, they didn't add replay-protection. Here are presented any proposals for getting replay-protection against BCash:

• @clashicly has been working on a hardfork-based solution https://github.com/clashicly/bitcoin-clashic/tree/0.15.101
• ...

Open to more proposals, ideas & feedback of any kind.

[clashicly]

There are 3 levels we can go

1. Change ANTI_REPLAY_COMMITMENT in chainparams.cpp 1a. This can be done immediately by Pools to invoke: return state.DoS(10, false, REJECT_INVALID, "bad-txn-replay", false, "non playable transaction"); 1b. It can activate at a given height, but there needs to be two possible values for ANTI_REPLAY_COMMITMENT for before and after the height is reached.

Nodes that don't upgrade will continue to relay transactions, but upgraded pools will not add those transactions to blocks.

2. Node connectivity 2a. Update DNSSeeds 2b. Update ServiceFlag from NODE_BITCOIN_CASH to NODE_BITCOIN_CLASHIC and invoke DoS logic from net_processing.cpp

3. Update SignatureHash() to use a SIGHASH_FORKID != 0x40 We would need two values for SIGHASH_FORKID, before and after the height is reached. Bitcoin Gold had a interesting way of using FORKID_IN_USE in SignatureHash()

[clashicly]

Another thing to consider is changing ports as per @prusnak Change default port number

This would be a courtesy to both Bitcoin and Bitcoin Cash. But difficult to execute on live network. This would also be an advantageous move for us, as Bitcoin full nodes with enough disk space would consider supporting Bitcoin Clashic. They can run our QT client in the background out of the box.

[clashicly]

Other downstream considerations are Bisq & CryptoBridge, as well as functionality out of the box with Trezor with custom backend.

[nothingmuch]

Just to complement the current discussion, I'll be focusing on what can be done with current consensus rules.

For a transaction to be replay protected, it must consume at least one output that is unique to the intended chain, or which has already been consumed on all other chains.

Every output consumed by a normal transaction can be traced back to some initial coinbase outputs. All coinbase transactions before the split are shared, and all coinbase transactions after the split are unique to that chain. Mixing post-fork mined coins in a transaction is a reliable way of restricting it to one chain.

Another possibility for replay protection is that given a valid txn, for every chain it may be replayed on, at least one of its inputs has been spent already.

For a transaction to be replayable it must spend only outputs from the initial UTXO set.

To fully determine that, one can envision a service that connects to multiple txindex nodes on different sides of a split (similar to https://btcforkmonitor.info/ or http://findmycoins.ninja), and with respect to each chain can say:

• is a txn ID confirmed on that chain?
• is a txn ID known to the node? (in mempool)
• is a txn (signed or unsigned) formally valid on that chain?
• is a txn valid with respect to the current utxo set of that chain?
  • if not, for every output it spends, is it:
  • already spent
  • spendable
  • unknown
    • if known on another chain, recursively determine:
    • it will never be spendable on this chain (descendent from coinbase of another chain)
    • may be spendable on this chain (descends from replayable transactions)
      • has it already been spent on all those chains
• is a txn valid with respect to the current mempool?

This is fairly exhaustive and would allow a full appreciation of the risk of any given transaction, including 0 conf.

Sticking to only confirmed transactions, something that takes as input txn IDs with optional output numbers and returns the recursive spendability information would be sufficient to allow users of any wallet to protect themselves (similar to how one might check txn state on an explorer).

As for actually splitting coins, I think the safest way for users to obtain tainted coins would be joinmarket, I suspect pre-segwit versions would work on both bcash and bclashic. Alternatively maybe someone wants to spend a few bucks to mine a segwit activation period on clashic, but who knows if full nodes will actually enforce it ;-)

Another way to obtain split coins is similar to electrum's method, using replayable but not replayed transactions, using different fees, ~RBF~, CPFP, or other tricks to get a double spend confirmed on two divergent chains

An easy but identity linking (also on other chains!) method to ensure any wallet is replay protected is to receive some tainted dust and then consolidate all the inputs.

Hopefully these pointers are helpful for anyone trying to split their coins.

If there is any interest I'd be happy to put together a proof of concept of the UTXO checker thing, the simplest iteration, I initially was going to do one for @chainsplit but I kind of suspect the bcash hard fork would be the last non replay protected fork we'll ever see and I wasn't sure how much interest there actually was, and eventually got bogged down with other projects as activity on @chainsplit slack died down.