Question about Replay Protection

[butka]

I keep reading (hearing) about replay protection in the context of Bitcoin Forks.
Here is what I've figured out so far:
When a fork happens, the same set of unspent transaction outputs (UTOs) are present on both sides of the fork and are controlled by the same private key.
If I understand it correctly, the problem arises when someone decides to spend some UTOs on one of the chains. An attacker may intercept and use the same
transaction signature to spend the equivalent UTOs on the other chain.
A solution that comes to mind could be to spend the UTOs on both chains at (nearly) the same time with high enough fees to ensure that both transactions
are mined as soon as possible.
Questions:
Is this attack just in the domain of theory, or has it happened before?
If the fork is friendly, should there be a mechanism in place to protect users against replay attacks, or in other words,
is there a way to implement Replay Protection globally?
How can this be done properly and whose responsibility is it to implement it (the people in charge for the fork)?

[1714193890]

1714193890

[1714193890]

1714193890

[1714193890]

1714193890

[DannyHamilton]

A solution that comes to mind could be to spend the UTOs on both chains at (nearly) the same time with high enough fees to ensure that both transactions
are mined as soon as possible.

Correct.

Once both have confirmed, they will be two separate UTXO and it will no longer be possible to replay a transaction spending one of them on one chain to the other chain.

Questions:
Is this attack just in the domain of theory, or has it happened before?

It is a very easy attack to accomplish if replay protection is not available in forked code.  I don't know if there have been any forks without built in replay protection yet.  If there have, I don't know if anyone has tried the attack yet.

If the fork is friendly, should there be a mechanism in place to protect users against replay attacks,

Even if the fork is NOT friendly, there should be a mechanism in place. For the protection of your own chain and users.

or in other words,
is there a way to implement Replay Protection globally?

When a fork is created, the code can modify the transaction validation process such that transactions from the other fork are invalid. In that way, transactions won't be able to be replayed from one fork to the other.

How can this be done properly and whose responsibility is it to implement it (the people in charge for the fork)?

It is the responsibility of the users to be aware of what their software does and decide whether it protects them adequately.

[butka]

When a fork is created, the code can modify the transaction validation process such that transactions from the other fork are invalid. In that way, transactions won't be able to be replayed from one fork to the other.

Thanks for the explanation. It makes perfect sense, and I guess it could be done without too much trouble.

[suchmoon]

A solution that comes to mind could be to spend the UTOs on both chains at (nearly) the same time with high enough fees to ensure that both transactions
are mined as soon as possible.

A more reliable protection would be to mix in UTXOs that exist only on that chain, e.g. coins minted after the fork.

[DannyHamilton]

A solution that comes to mind could be to spend the UTOs on both chains at (nearly) the same time with high enough fees to ensure that both transactions
are mined as soon as possible.

A more reliable protection would be to mix in UTXOs that exist only on that chain, e.g. coins minted after the fork.

Once both of the transactions described by butka have confirmed, neither of the UTXO will exist on the other chain.  Therefore, they can be used to mix with UTXO's that are on both chains without needing to obtain special bitcoins that were only mined on one chain.

[Wind_FURY]

Questions:
Is this attack just in the domain of theory, or has it happened before?

Bitcoin Cash in the beginning did not provide automatic replay protection, it was opt in before. Not really what you were asking for but I believe it is close enough.

If the fork is friendly, should there be a mechanism in place to protect users against replay attacks, or in other words,
is there a way to implement Replay Protection globally?

Is there such a thing as a "friendly" fork? Something to think about.

How can this be done properly and whose responsibility is it to implement it (the people in charge for the fork)?

They should start their own genesis block.

[butka]

Bitcoin Cash in the beginning did not provide automatic replay protection, it was opt in before. Not really what you were asking for but I believe it is close enough.

Yes it is. Thank you for mentioning BCash. Given all the buzz and fuss surrounding their fork, I was wondering how they solved this problem.

[odolvlobo]

If I understand it correctly, the problem arises when someone decides to spend some UTOs on one of the chains. An attacker may intercept and use the same transaction signature to spend the equivalent UTOs on the other chain.
A solution that comes to mind could be to spend the UTOs on both chains at (nearly) the same time with high enough fees to ensure that both transactions are mined as soon as possible.

The problem of replay is not necessarily due to an attack.

Without some sort of replay protection, if a node is connected to nodes on both sides of the fork, then any transaction it relays will be executed on both chains. Your proposed solution will not work.