Topic: Question regarding replay attack (Read 233 times)

.

if you want simple answer, then YES it can be done

---

long answer with explanations you can read below, otherwise skip/ignore it

can be done as long as the unspents are valid on the chain that attacker plans to do replay attack
but when both devs of coins already implemented replay-protection, you don't need to worry anymore
unless the coin doesn't implement it, then a replay attack can be done on that coin chain

short example what to do if replay-protection doesn't exist:
bitcoin: unspent1AddrA + unspent1AddrB + unspent1AddrC---> unspent1AddrF
bitfork: unspent1AddrA ---> unspent2AddrC
do it at the same time and get confirmation on both chains, you are safe from replay attack

if you do as follow below and replay-protection doesn't exist then your coins are NOT safe:
bitcoin: unspent1AddrA ---> unspent1AddrF ---> unspent1AddrG ---> unspent1AddrH
bitfork: no tx
you are still susceptible to replay attack if no replay protection implemented on bitfork chain
eventhough your bitcoin already moved 3 times, it still can be replayed anytime on bitfork

ah yeah my bad i didn't read carefully, well this answer my question, which was also very clear from the second post

"my concern was about an attack done on another fork where the coin are already associated with another private key", required only a no or yes really...

I think you misunderstood him, he clearly said that if you have moved your Bitcoins to a new address, they can no longer be replay attacked by transactions from an old address that you have claimed on forked chain:





No, moving forked coins to a new address (even within same wallet) after you have imported private key (that should now be empty on BTC chain) is done to protect your forked coins from someone replaying your BTC transactions to forked network.


Basically, as a rule of thumb, you should always check inputs on block explorers of both chains - if they are identical, then transaction can be replayed. All this moving before actually spending is done to create a situation when an input is spent on one chain but still unspent on the other.

i already moved them before dumping my private key and waited enough confirmations, but from Danny post, it seems that there is still the possibility to do a replay attack on the bitcoin network, even if you moved your bitcoin to another address before claiming your bitcoin forked coin

so by your post i need to move my forked coin to another address that i own, to make it invalid to do a replay attack on the bitcoin network right?

Transactions can't be replayed if they use as an input coins that were already spent on a chain that you are trying to replay to and that spending transaction was already included in block.

I assume you want to protect your BTC from replays while claiming the upcoming forks, then you should move your BTC to a new wallet (this will also remove the possibility of fork wallets stealing all your private keys) after the fork date, and wait at least 6 confirmations on BTC network. Lets say you moved all your BTC from your address A of wallet1 to address B of your wallet2.

Now, if this BTC transaction A->B wasn't replayed to forked network (can happen on its own if forked nodes are connected with BTC nodes), you will have your forked coins on A* address, and if you'll move it to another address, like E*, transaction A->E would be invalid on BTC network, because on BTC network A was already spent. So, when you will import your wallet1 keys to a forked client, make some transaction A*->E* to prevent the risk of A->B being replayed to forked network.

It depends on the specifics of the lack of replay protection.  Sometimes replay protection is availabe in one direction and not the other.  If replay protection is not available in either direction, then the following is also true:

Lets imagine you have some bitcoins.

Now lets imagine that a new Bitcoin Fork happens (we'll call the fork Bitcoin-Replay for the sake of this conversation), and that this fork does NOT have replay protection.

Now, after the fork, lets say you send some of your Bitcoin-Replay coins to a new Bitcoin-Replay address (a merchant, or an exchange, or whatever).

Because there is no replay protection, anybody can take your Bitcoin-Replay transaction and re-broadcast that same transaction on the Bitcoin network.  When they do, the exact same amount of Bitcoins will be sent to the exact same address on in the Bitcoin system (even though you only intended to send your Bitcoin-Replay coins and not your Bitcoins).

That is a "replay attack" because the Bitcoin-Replay transaction was "replayed" on the Bitcoin network.

It won't matter if your Bitcoin-Replay transaction has 10,000 confirmations, or if your Bitcoin-Replay coins were sent a thousand more times.  That initial Bitcoin-Replay Transaction is STILL a valid Bitcoin transaction and can STILL be sent on the Bitcoin network, forcing your Bitcoins to move without your permission.

Now, if YOU send all of your Bitcoins to a new address intentionally, as soon as that transaction gets 1 confirmation the Bitcoin-Replay transaction will no longer be valid on the Bitcoin network.  It will no longer be possible to replay the Bitcoin-Replay transaction on the Bitcoin system.


Possible, or possibly not.  It all depends on the specific implementation of the fork and what sort of replay protections are available in each direction.


It is possible to create a fork that has a transaction format that is valid on the Bitcoin network.  In that case, then fork transaction can be replayed on the Bitcoin network.


That depends on the specifics of how the transaction is formatted in the forked system.  There aren't actually any addresses in Bitcoin transactions.  Addresses are something that our wallets use in the user interface to make it easier for us to work with the concept of transferring control over value.  In the actual transaction there is just a script.  In the case (as an example) of a P2PKH address (Bitcoin addresses that start with a 1) the script includes a hash of the ECDSA public key.

The fork might choose a different address representation, but if it uses a similar scripting system and similar hashes, then the value can still be transferred even though the wallet uses a different address to show the user, because the underlying transaction might still be the same on both systems.

no i didn't get scared i just want to understand how it work, my concern was about if i move the forked bitcoin, my bitcoin will move together with them, but you are saying the opposite, that the forked coin will move

which mnean that at worst i would lose the forked coin...which make sense because this is the one without replay protection i didn't get this at first

also the address format is different how can the forked coin can be sent to the exact same address?

Do you understand what a replay attack is?  Or did you just hear the words "replay attack" and get scared?

Lets imagine you have some bitcoins.

Now lets imagine that a new Bitcoin Fork happens (we'll call the fork Bitcoin-Replay for the sake of this conversation), and that this fork does NOT have replay protection.

Now, after the fork, lets say you send some of your bitcoins to a new bitcoin address (a merchant, or an exchange, or whatever).

Because there is no replay protection, anybody can take your Bitcoin transaction and re-broadcast that same transaction on the Bitcoin-Replay network.  When they do, the exact same amount of Bitcoin-Replay coins will be sent to the exact same address on in the Bitcoin-Replay system (even though you only intended to send your Bitcoins and not your Bitcoin-Replay coins).

That is a "replay attack" because the bitcoin transaction was "replayed" on the Bitcoin-Replay network.

It won't matter if your bitcoin transaction has 10,000 confirmations, or if your bitcoins were sent a thousand more times.  That initial Bitcoin Transaction is STILL a valid Bitcoin-Replay transaction and can STILL be sent on the Bitcoin-Replay network, forcing your Bitcoin-Replay coins to move without your permission.

Now, if YOU send all of your Bitcoin-Replay coins to a new address intentionally, as soon as that transaction gets 1 confirmation the Bitcoin transaction will no longer be valid on the Bitcoin-Replay network.  It will no longer be possible to replay the Bitcoin transaction on the Bitcoin-Replay system.

you mean that if i spend two times it's not feasible to do it anymore? my concern was about an attack done on another fork where the coin are already associated with another private key and 10k confirmation, so if i move them again the replay attack it's not possible to do anymore right?

take bitcoin gold, i move my bitcoin and wait 10k confirmation, then i dump the private key on bitcoin gold that let's assume have not any replay protection, now i move again my bitcoin and move then my bitcoin gold to an exchange(so i can't control the private key) let's say

it's still feasible to do an attack in this case?

Yes. It can happen, no matter how much confirmations you have. The nature of replay attack exploits the validity of the transactions between two forks of the chain.

However, it won't be easy to pull off. For the attack to work, your transaction has to be valid on both chain. The forked chain must not have implemented any replay protection. This also means that at the moment of the attack, the inputs has to be unspent and valid on the chain which you are attacking on.

how far a replay attack can go back in time? i mean if i have a TX with 10k confirmations can still be attacked with a replay attack? is it limited by time?