Easy Way to protect funds from lack of replay protection in comiong fork

[Colorblind]

As I see it, I can easily protect my assets from lack of replay protection is by performing transaction  of all my funds located on one of the chains to some wallet I control, then wait until it gets confirmed by that chain and make sure it wasn't confirmed by the other chain. This way replay of any following transactions of my funds on either chains won't be valid for both chains.

Or am I missing something here?

[PVminer]

As I see it, I can easily protect my assets from lack of replay protection is by performing transaction  of all my funds located on one of the chains to some wallet I control, then wait until it gets confirmed by that chain and make sure it wasn't confirmed by the other chain. This way replay of any following transactions of my funds on either chains won't be valid for both chains.

Or am I missing something here?

It is not enough. You have to spend coins to a different post-fork address on both chains. Because there is nothing that can stop anyone from taking transactions from chain 1 and broadcasting it on chain 2 even after confirmation (maybe some guys wanting to create as much disruption as possible have already created automated tools for that). Even if it is confirmed in block xxxx on chain 1, it can be confirmed in block xxxx+n on chain 2 and you again have coins related to the same address on both chains. But as soon as the coins are confirmed with different addresses on both chains, they cannot be replayed.

Read here a detailed explanation: https://bitcointechtalk.com/how-to-protect-against-replay-attacks-7a00bd2fe52f

[Colorblind]

As I see it, I can easily protect my assets from lack of replay protection is by performing transaction  of all my funds located on one of the chains to some wallet I control, then wait until it gets confirmed by that chain and make sure it wasn't confirmed by the other chain. This way replay of any following transactions of my funds on either chains won't be valid for both chains.

Or am I missing something here?

It is not enough. You have to spend coins to a different post-fork address on both chains. Because there is nothing that can stop anyone from taking transactions from chain 1 and broadcasting it on chain 2 even after confirmation (maybe some guys wanting to create as much disruption as possible have already created automated tools for that). Even if it is confirmed in block xxxx on chain 1, it can be confirmed in block xxxx+n on chain 2 and you again have coins related to the same address on both chains. But as soon as the coins are confirmed with different addresses on both chains, they cannot be replayed.

Read here a detailed explanation: https://bitcointechtalk.com/how-to-protect-against-replay-attacks-7a00bd2fe52f

Oh thanks! That's a nice catch of flaw in my logic.

[Carlton Banks]

It is not enough. You have to spend coins to a different post-fork address on both chains.

Even that's not enough.

An automated replay attacker can still broadcast the transactions from the BTC chain and the B2X chain on the opposite chain. There exists a risk that either transaction will confirm on the chain that you don't have the private keys for. It depends which transaction the miner who mines those transaction sees first, which is not necessarily going to be your intended transactions with the correct addresses.

[PVminer]

It is not enough. You have to spend coins to a different post-fork address on both chains.

Even that's not enough.

An automated replay attacker can still broadcast the transactions from the BTC chain and the B2X chain on the opposite chain. There exists a risk that either transaction will confirm on the chain that you don't have the private keys for. It depends which transaction the miner who mines those transaction sees first, which is not necessarily going to be your intended transactions with the correct addresses.

No, it is enough  But indeed it is not easy to make sure the coins land on different chains.

Suppose you own keys K0, K1, and K2. K0 correspond to inputs pre-fork. If you send K0->K1 on chain 1 and K0->K2 on chain 2, they will be protected if both are confirmed on the respective chains (baring reorganizations). After including in the blockchains, if you send K1, they will not be recognized on chain 2 and K2 on chain 1 because no coins exists on these addresses on the other chain.

Reorganizations may wreck havoc to this plan though and I would wait at least a few dozen of blocks before sending coins to addresses I do not control.

Of course if you send K0->K1 on chain 1 and K0->K2 on chain 2, you may end up with K1 on both chains or K2 on both chains. In this case, rinse and repeat with another pair of keys you own. Except for the fees, there is no harm doing it many times.

The article  I linked shows how to increase the chance of successful coin split  with Locktime.

[Carlton Banks]

You're not getting it


If (post-fork) you send K0 > K1 on BTC chain, and K0 > K2 on B2X chain, what's stopping a replay attacker from swapping those, i.e. broadcasting K0 > K2 on BTC chain and K0 > K1 on B2X chain?


Nothing. You might say "unlikely the replays will confirm", which is why I already said "it depends which transaction the miner who mines those transaction sees first, which is not necessarily going to be your intended transactions with the correct addresses"


What you're suggesting is not guaranteed to fail. But it's not guaranteed to work either, it depends if there's someone out there who's going to cause that kind of chaos. (let's be honest, best not to bet against that).

[PVminer]

What you're suggesting is not guaranteed to fail. But it's not guaranteed to work either, it depends if there's someone out there who's going to cause that kind of chaos. (let's be honest, best not to bet against that).

If two chains have different length, sending a transaction with LockTime=longer_chain_height guarantees that the shorter will not pick it up before longer_chain_height. If the difference is several blocks, you have enough time to have a confirmation on chain1 and to make a separate transaction on chain2. Since LockTime is part of the signature, it cannot be changed by evil replayer.

Many wallet clients set up LockTime=current_block_height so such procedure should work even without manual LockTime modifications. So as long as you send the transaction on longer chain first, you should be able to split the coins if the two chains have enough block height separation.

[Carlton Banks]

If two chains have different length, sending a transaction with LockTime=longer_chain_height guarantees that the shorter will not pick it up before longer_chain_height. If the difference is several blocks, you have enough time to have a confirmation on chain1 and to make a separate transaction on chain2. Since LockTime is part of the signature, it cannot be changed by evil replayer.

Many wallet clients set up LockTime=current_block_height so such procedure should work even without manual LockTime modifications. So as long as you send the transaction on longer chain first, you should be able to split the coins if the two chains have enough block height separation.

Yes, that method could work. You didn't mention using LockTime in your original post though.

It's not ideal, even still. The user will pay quite high fees to feel confident that the LockTime won't expire before the transaction confirms, and there are still no guarantees even then.

[illinest]

If (post-fork) you send K0 > K1 on BTC chain, and K0 > K2 on B2X chain, what's stopping a replay attacker from swapping those, i.e. broadcasting K0 > K2 on BTC chain and K0 > K1 on B2X chain?

Nothing. You might say "unlikely the replays will confirm", which is why I already said "it depends which transaction the miner who mines those transaction sees first, which is not necessarily going to be your intended transactions with the correct addresses"

As long as you control both receiving addresses, you're safe. The first step is to split the coins into addresses that you control. It would be very risky to send un-split coins as payment with the intention of the transaction confirming only on one chain.

My thinking is: 1) Send K0 > K1 (RBF+timelock) and K0 > K2 (standard transaction). 2) Re-send K0 > K1 with a higher fee and no timelock once the K0 > K2 transaction has confirmed. It doesn't matter which chain it confirms on. If it confirms on B2X, the new RBF transaction will only be valid on the legacy chain. On the B2X chain, those outputs would have already been spent and confirmed in a previous block.

Am I approaching this wrong? It's hacky, but I think it should work.

[Wind_FURY]

Is there a better and safer way to split our coins though? I hope a Bitcoin developer would make a tool for this to make it easier. I have most of mine in cold storage but I would be willing to sweep my private keys to get my free B2X, but only if safe to do.

My second option is to keep some in an exchange for a quick B2X dump.

[gentlemand]

Is there a better and safer way to split our coins though? I hope a Bitcoin developer would make a tool for this to make it easier. I have most of mine in cold storage but I would be willing to sweep my private keys to get my free B2X, but only if safe to do.

My second option is to keep some in an exchange for a quick B2X dump.

https://docs.google.com/document/d/13c5YMqR72xaa23ohmg7M9heJbu59IvamSTQIVGFAY6c/edit#heading=h.bzax9ow35x4o

It looks like they are working on something to address this. I'm not sure how quickly it'll arrive. The only wallet provider I'm aware of who's providing splitting ASAP is Ledger.

[PVminer]

There is a way you can prevent this.
Say if you have 10 btc in your wallet .before the fork you need to send .001btc to this wallet from some other wallet after the fork.
By doing this now you have 10.001 btc in the 1st wallet and this is new ballence and it cannot be replayed as snap shot is already taken at 10btc.
Correct me if iam wrong here.

It works only if 0.001 BTC transfer is not replayed on the other chain for which there is no guarantee (unless the funds come form coinbase or are in one chain only, or are carefully created with Locktime). And then, only if there is no chain reorganization.

[marky89]

Is there a better and safer way to split our coins though? I hope a Bitcoin developer would make a tool for this to make it easier. I have most of mine in cold storage but I would be willing to sweep my private keys to get my free B2X, but only if safe to do.

Some developers are working on a non-custodial coin splitting service. I've browsed through the Github and there are some names I recognize. The #utxoseparation Slack channel is for high level discussion. You can get more info here:

https://twitter.com/ChainSplit
https://github.com/chainsplit
https://join.slack.com/t/utxosplitter/

My second option is to keep some in an exchange for a quick B2X dump.

I'm tempted to the do the same, but after the Bitfinex "hack" last year I'm weary of keeping more than 5-10% of my coins on an exchange. It doesn't seem worth it. With Changelly seemingly catering to the #NO2X side, I wonder if they'll offer a coin splitting service.