Question about Replay Protection | Bitcointalksearch.org

odolvlobo

legendary

Activity: 4466

Merit: 3391

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

butka

full member

Activity: 434

Merit: 246

Quote from: Wind_FURY on May 17, 2018, 02:15:18 AM

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.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

Quote

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.

Quote

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.

DannyHamilton

legendary

Activity: 3472

Merit: 4794

Quote from: suchmoon on May 16, 2018, 04:00:08 PM

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

suchmoon

legendary

Activity: 3654

Merit: 8909

https://bpip.org

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

butka

full member

Activity: 434

Merit: 246

Quote from: DannyHamilton on May 16, 2018, 01:38:43 PM

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.

DannyHamilton

legendary

Activity: 3472

Merit: 4794

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

Quote from: butka on May 16, 2018, 01:27:32 PM

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.

Quote from: butka on May 16, 2018, 01:27:32 PM

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

full member

Activity: 434

Merit: 246

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)?

Topic: Question about Replay Protection (Read 264 times)