Zero footprint 2-way replay protection
Last year I was invited to the bitcoin fork slack and the need for 2-way replay protection was made pretty clear by the ETC release that didnt have replay protection.
I wanted to come up with a method that was efficient and easy to implement and I believe I suceeded. Last summer, I made a post to steemit about it:
https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changesBCH had a different method that increased the txsize in parallel with the sighash_forkid method for a while, where it was optional. But in the end they decided to require the sighash_forkid. Their implementation added a twist to it by using segwit non-malleable signatures for the forkid path, but the concept is the same.
The key idea is quite simple. In order to make 2-way replay protection work, the signature for the new fork is made incompatible for any other fork. Since the signature is not compatible, it will also reject valid signatures from other forks.
The way to achieve this requires to understand a bit about the bitcoin signing internals. Actually, just one thing. The signature doesnt actually sign the raw tx bytes, but rather a 256-bit hash. this hash is created based on the rawtx, but it is converted in complex ways. however, it isnt needed to understand the exact conversions, just that the hash is unique for the rawtx. My sighash_forkid method changes some bytes in the data that generates the hash based solely on what blockchain it is coming from.
It is like adding a brandname to the prehash data and this allows the creation of 2-way replay protection, but actually it is far more, it is 2-way protection against all prior forks!
Now the BCH code is out there, BTG gold was able to implement it with just adding a BTG specific forkid #define. SBTC made a string concatenation of "sbtc" to the prehash data to the original signing path and would be the simplest to emulate.
For barterDEX, I want to support as many bitcoin forks as possible and if they are providing 2-way replay protection we will do our best to add support. However, if the tx format is bloated and some additional output or opcode is needed (for every tx!) to avoid replay protection, this is an unfortunate choice as it not only bloats the blockchain with every tx for something that didnt have to, it also wont be compatible with barterDEX atomic swap code.
If in doubt as to what magic values to use, a bitcoin fork project can contact us as we will necessarily be monitoring and maintaining a bitcoin fork compatibility list. Also, I believe the days of simple btc clone forks having much value will be coming to an end. just like altcoins used to just be pure clones without any unique new features and it was sufficient, but nowadays an altcoin must have its own unique features, so it will be for bitcoin forks.
