1

This blog post describes a method for protecting against replay attacks after any hard fork on the Bitcoin blockchain. It asumes you have BTC in a wallet and want to transfer it without risking the forked coin.

In summary it says:

  1. Buy BTC in an exchange
  2. Transfer BTC from exchange to your wallet
  3. Transfer full amount including newly received BTC from wallet to another wallet

According to the author, the last transaction can't be replayed on the new chain since it is for a larger amount than what that address would have in the new chain.

Can someone confirm whether this does in fact protect from replay attacks? Would this be a valid method for any hard fork?

My concern is that somebody could replicate the first transfer (step 2) in the new chain, therefore making the second transaction (step 3) replay-able.

2
  • Perhaps the assumption is that the exchange wants to keep the forked coin instead of sending it to you, so you presume that they will have taken steps to ensure that the step 2 transaction is not replayable. If so then step 3 would be safe. Commented Oct 29, 2017 at 21:42
  • @NateEldredge It is not just an assumption. The author says that although it is not properly explained (see my answer).
    – karask
    Commented Oct 30, 2017 at 10:54

2 Answers 2

2

this does in fact protect from replay attacks?

no

Would this be a valid method for any hard fork?

no

My concern is that somebody could replicate the first transfer

you are right

1
  • Although it is not explained properly the article covers the OP's concern. i.e. chances are that the exchange would block replay attacks (by splitting) so as not to give free coins.
    – karask
    Commented Oct 30, 2017 at 11:01
1

Your concern is valid. However, the author mentions this.

"... Check your other pile if there is also something being added to that. If there is, keep buying on that exchange because they are sending you free coins! But normally these exchanges will understand that they can split their coins as well, and you should not get these extra coins."

7
  • Not sure how that addresses the issue of my outgoing transfer being replayed.
    – twalbaum
    Commented Oct 29, 2017 at 19:21
  • When you buy BTC in an exchange you will buy only BTC. The exchange will make sure that you don't automatically get coins on the other chain. Thus it cannot be replayed! If the exchange doesn't split your addresses properly then although the replay will be possible it will just be free money for you on the 2nd chain! Even in that case the author suggests that you can keep buying and receiving free coins until the exchange realizes what is happening and splits your addresses. From then on the replay won't be possible.
    – karask
    Commented Oct 30, 2017 at 10:44
  • Having said that since exchanges don't like giving free coins they would almost certainly have already split your addresses; thus no replay possible in the first place (your step 2). I agree that the article doesn't explain it properly but it covers your (valid) concern.
    – karask
    Commented Oct 30, 2017 at 10:49
  • Still, if you want to be safe, there is a missing step in between 2 and 3: "check if the transaction from the exchange was replayable". And it's not sufficient just to look at your forkcoin client and see if more funds arrived, because it's possible that the transaction is replayable but simply hasn't been replayed yet. Commented Oct 30, 2017 at 12:43
  • 1
    @morningstar: Look at the inputs of the transaction. If, on the other chain, at least one of them exists and has been spent (by a confirmed transaction), then you can be assured that it is not replayable. If all of them exist and are unspent on the other chain, then it is replayable. If they don't exist on the other chain, it becomes more difficult to be sure. Commented Nov 8, 2017 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.