1
I was reading on replay vulnerabilities introduced by forks which only implement opt-in replay protection. Let 'X' be the 'legacy chain' (BTC) and let 'Y' be the forked chain (BTG). Now, if I understand correctly, in practical terms, an attack implies that a transaction 'G' on chain 'Y', can be replayed on chain 'X' (say transaction 'H'), hence the transacted amount will be deduced from coin stored on both chains.
I understand that if I move all (or part?) coin from chain 'X' to 3rd chain, say 'Z' (BCH for example, and let's call the transaction 'I'), prior to transacting on chain 'Y', the potential hypothetical 'attack' transaction 'H' cannot occur since the blocks on chain 'X' were already transacted to chain 'Z'. Do I stand correct?
Afaik segwit2x implements a similar way of opt-in protection, just that transaction 'I' has to be done to a specific address '3Bit....'. Is there a difference between the segwit 2x and my propesed protection mechanism, other than sending an amount of coin to an address which is not mine?
I don't see what your proposed protection mechanism is. – Pieter Wuille – 2017-10-11T16:40:00.393
To completely get rid of coins on 'X' before transacting on 'Y'... – orthogon – 2017-10-11T16:53:32.643
2How do you get rid of your coins on X without also getting rid of your coins on Y? The point of replay is that transactions on one side are equally valid on the other. – Pieter Wuille – 2017-10-11T17:44:09.423
1Also, you can't move coins from one chain to another. You can exchange them for the currency on the other chain, but that still implies you're sending your money to a counterparty. When transactions are replayable, the counterparty will receive both your X and Y coins. – Pieter Wuille – 2017-10-11T18:26:01.953