- Some people here say, that for a replay of a transaction on the other side "someone else" need to take the transaction and broadcast it on the other side.
This is not true.
With the upcoming fork, the legacy chain and the Segwit2x chain broadcast their transactions to the same network. So, whenever you send a transaction (does not matter on which side), the transaction will always find a way to the nodes of the other chain (they are in the same network, they share the same transaction pool and so on). This causes always a replay of any transaction sent to the network. - The only save way to split the coins I know is with a time locked transaction.
The idea here is, that after a split both chains will have a different hash rate. So it is very unlikely that they find new blocks with the same speed. The chain with more hash rate will find blocks faster than the one with less hash rate.
Let's assume the chain splits at block height 1000 (I know the current block height is higher, but just as example).
This means, that from block 1000 on, the blocks will look different.
Lets say with hash rate of Chain A they will find blocks every 20 minutes, Chain B find blocks every 40 minutes. After 6 hours Chain A created 18 blocks (block height 1018) and Chain B created 9 blocks (block height 1009).
Now comes the magic part.
You create a transaction with the bitcoins you want to split and send them to a new address you created before (important, you need to send to an address you control the private key!!). The transaction should have the nLocktime Parameter set to the block height of the longer chain. In this example, set the nLocktime to 1018. This means, that this transaction is only allowed to add to a new block if the block height of the chain is equal or higher than 1018.
Chain A has height 1018, so if you payed enough transaction fee, the transaction should be put into one of the next blocks.
Chain B has height 1009, so this transaction with the locktime 1018 will not be mined into the next blocks. It will wait in the transaction pool until Chain B reaches height 1018.
When this transaction got one confirmation on Chain A, you create a second transaction to a different address you created (also your own address), but this time without time lock.
The second transaction will be picked up by Chain B and put into one of the next blocks. This makes the first unconfirmed transaction invalid on Chain B. The second transaction itself is invalid on Chain A, because the Bitcoins were already used in the first transaction.
If everything was working fine, you should have your coins on a new address on Chain A and another new address on Chain B. - There is a chance, that this coin split might not work the first time.
For example, if your first transaction did not get confirmed, before the second chain reach the nLockTime block height. In this case, you just wait again, until the two chains have a different height (maybe 10 to 20 blocks difference), and try again (that's the reason why you should always do this split and send the coins to your own addresses, so you can repeat in case it did not work the first time).
I hope that it is understandable what I wrote there
One challenge is to create this nLocktime transaction, as I don't know any "easy" way to create them. Wallets usually don't support to create them directly...
Kogs, I see what you're getting at, but is it really necessary to timelock the transaction? Assuming you're sending the coins to an address only you have the private key for, then the worst case if a replay occurs is that your coins get moved to an address you control and you could just start over, right? Could you not just send the transaction, then once it arrives at its destination in one chain, safely send the same coins to a different address using the client for the other chain? It's a race, and whoever wins will just ignore the second attempt as a double-spend.
Let me know if I missed something here.
ps. Sorry to revive an old post but I wanted to reference the original message.
