<blockquote>
  <p>this does in fact protect from replay attacks?</p>
</blockquote>

<p>no</p>

<blockquote>
  <p>Would this be a valid method for any hard fork?</p>
</blockquote>

<p>no</p>

<blockquote>
  <p>My concern is that somebody could replicate the first transfer </p>
</blockquote>

<p>you are right</p>

CC BY-SA 3.0
2017-10-30T11:01:28.993Z
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
CC BY-SA 3.0
2017-10-29T06:29:13.190Z
2017-10-29T06:29:13.190Z
amaclin
<p>Your concern is valid. However, the author mentions this.</p>

<p>"... 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."</p>

CC BY-SA 3.0
2017-10-29T19:21:12.497Z
Not sure how that addresses the issue of my outgoing transfer being replayed.
twalbaum
CC BY-SA 3.0
2017-10-30T10:44:40.627Z
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
CC BY-SA 3.0
2017-10-30T10:49:54.270Z
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
CC BY-SA 3.0
2017-10-30T12:43:55.790Z
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.
Nate Eldredge
CC BY-SA 3.0
2017-10-30T16:38:42.523Z
Yes, this is true. Not arguing against being careful.. just mentioning that the author mentioned it and chances are really slim given that the exchanges wouldn't allow tx to be replayed (or else go out of business soon). Still, your point is valid.
karask
CC BY-SA 3.0
2017-11-08T04:13:35.453Z
@NateEldredge Can you explain a method for "check if the transaction from the exchange was replayable"?
morningstar
CC BY-SA 3.0
2017-11-08T19:44:43.213Z
@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.
Nate Eldredge
CC BY-SA 3.0
2017-10-29T19:13:38.837Z
2017-10-29T19:13:38.837Z
karask
<p>This <a href="https://blog.tenx.tech/bitcoin-fork-simple-trick-to-secure-your-coins-without-replay-protection-transcript-f1a58b08edf2" rel="nofollow noreferrer">blog post</a> 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.</p>

<p>In summary it says:</p>

<ol>
<li>Buy BTC in an exchange</li>
<li>Transfer BTC from exchange to your wallet</li>
<li>Transfer full amount including newly received BTC from wallet to another wallet</li>
</ol>

<p>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.</p>

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

<p>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. </p>

CC BY-SA 3.0
2017-10-29T21:42:11.053Z
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.
Nate Eldredge
CC BY-SA 3.0
2017-10-30T10:54:29.757Z
@NateEldredge It is not just an assumption. The author says that although it is not properly explained (see my answer).
karask
<blockchain-fork>
Does this method really work as replay protection?
twalbaum
# Does this method really work as replay protection?

(Asked by: username_0 on 2017-10-29)

This [blog post](https://blog.tenx.tech/bitcoin-fork-simple-trick-to-secure-your-coins-without-replay-protection-transcript-f1a58b08edf2) 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.

**Tags:** blockchain-fork

> **Comments:**
> **username_1**: 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.  
> **username_2**: @username_1 It is not just an assumption. The author says that although it is not properly explained (see my answer).  

---

## 2 answers

### Answer by username_3 on 2017-10-29. Score: 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

> **Comments:**
> **username_2**: 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.  

---

### Answer by username_2 on 2017-10-29. Score: 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."

> **Comments:**
> **username_0**: Not sure how that addresses the issue of my outgoing transfer being replayed.  
> **username_2**: 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.  
> **username_2**: 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.  
> **username_1**: 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.  
> **username_2**: Yes, this is true. Not arguing against being careful.. just mentioning that the author mentioned it and chances are really slim given that the exchanges wouldn't allow tx to be replayed (or else go out of business soon). Still, your point is valid.  
> **username_4**: @username_1 Can you explain a method for "check if the transaction from the exchange was replayable"?  
> **username_1**: @username_4: 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.  

---

