Replay protection ; Can it be done like this?

[schnuber]

Is it possible to protect against replay protection by the following simple steps:

1. Send your coins on one side of the forked chain into any address that you own.
2. Wait until the transaction is confirmed.
3. If during that time you get replayed, go back to step one. You still have access to all of your coins since you own the private key.
4. If you are not replayed, send the coins on the other chain to a different address.
5. Wait until confirmed... done, your coins are split.

Is that correct?

[1714125930]

1714125930

[1714125930]

1714125930

[yakuza699]

3. If during that time you get replayed, go back to step one. You still have access to all of your coins since you own the private key.

It is not a matter of "if". It will undoubtedly happen as long as the transaction is valid on both chains, so as soon as you broadcast one transaction on one chain it will instantly get relayed on to the other.
There are better "replay protections" than yours, just read the forums.

[schnuber]

It will undoubtedly happen as long as the transaction is valid on both chains, so as soon as you broadcast one transaction on one chain it will instantly get relayed on to the other..

Interesting, and why is that?

[exstasie]

Is it possible to protect against replay protection by the following simple steps:

1. Send your coins on one side of the forked chain into any address that you own.
2. Wait until the transaction is confirmed.
3. If during that time you get replayed, go back to step one. You still have access to all of your coins since you own the private key.
4. If you are not replayed, send the coins on the other chain to a different address.
5. Wait until confirmed... done, your coins are split.

Is that correct?

I believe you are correct. But presumably if the transaction wasn't replayed on the second chain, it will be replayed momentarily or is already in node mempools.

The thing is, there is great incentive to run scripts that automatically replay all network transactions, to give the appearance of significant network activity. The 2X side doesn't want to give the appearance of a dead network, and there is no fee disincentive to discourage replaying transactions. It's a free attack. So I wouldn't expect your plan to be viable most of the time. You might end up wasting a bunch of time and fees.

[schnuber]

The thing is, there is great incentive to run scripts that automatically replay all network transactions ...

Yes you are right. I guess the miners have incentive to replay transactions.

[Taras]

It will undoubtedly happen as long as the transaction is valid on both chains, so as soon as you broadcast one transaction on one chain it will instantly get relayed on to the other..

Interesting, and why is that?

All it takes is one single person to replay ALL of the transactions across both networks. So if one person is doing it, it doesn't matter how many times you make transactions, they will be on both chains. And it's more than likely that more than one person will do it, whether for fun or ulterior motives.

I'm betting your idea is a lot more likely to work if you skip step 2. Have two transactions at the same time, one on each chain, each going to a different address, and then repeat until one is confirmed on the main chain and the other is confirmed on the fork.

[Colorblind]

3. If during that time you get replayed, go back to step one. You still have access to all of your coins since you own the private key.

It is not a matter of "if". It will undoubtedly happen as long as the transaction is valid on both chains, so as soon as you broadcast one transaction on one chain it will instantly get relayed on to the other.
There are better "replay protections" than yours, just read the forums.

Would you kindly provide a link to those better options?

Also would it be possible not to broadcast transaction, but send them directly to certain miners to avoid being replayed then sit and wait till this miner finds a block that will include your transaction.
Edit: That won't work, because attacker can read blockchain and immidiatley replay transaction... damn.

[PVminer]

Would you kindly provide a link to those better options?

See discussion here:
https://bitcointalk.org/index.php?topic=2352924.msg23977271#msg23977271

Also, a sure way (baring reorganizations) is to include in the transaction a tainted coin, a coin that is valid on one chain only. Either because it was already split or it is a freshly mined coin on one of the chains.

Also would it be possible not to broadcast transaction, but send them directly to certain miners to avoid being replayed then sit and wait till this miner finds a block that will include your transaction.

Do you have a direct link to certain miners? Are you sure they are not going to rebroadcast the transaction?

And always, there is a risk of chain reorganizations.

[mentalpanda]

I agree with those who things that Bitcoin is in danger due to hardfork without a reply protection. I don't say never in computer science but it is very unlikely that we can find a solution for these attacks. I don't think it will be the end of Bitcoin, but i am very certain that Bitcoin will have difficult days following the hardfork. I hope time will prove me wrong.

[Navigo]

As far as i know, there is no escape from this attacks. I am sure that a lot of people will try this and it will cause a small chaos after the hardfork. This is done on purpose so people eventually get one shot to chose which chain they see as "real bitcoin". It is disrespectful and completely against the whole idea of Bitcoin. It is not up to anyone else to limit my economic decisions.

[cryptonighty100]

wasnt it like :
sending a little btc amount to your big money btc wallet
so that the btc and the btc2x money arent the same amount -
and then you send the overall btc amount to another wallet ?
so the btc2x money wouldnt sent because of not insufficent funds ?

[desmodiAN]

>> so as soon as you broadcast one transaction on one chain it will instantly get relayed on to the other
bad thing if all forks use same rules for accepting tx. shows that the fork is an attack not an upgrade or anything

[Thirdspace]

wasnt it like :
sending a little btc amount to your big money btc wallet
so that the btc and the btc2x money arent the same amount -
and then you send the overall btc amount to another wallet ?
so the btc2x money wouldnt sent because of not insufficent funds ?

won't work, there is no guarantee that your little amount is not replayed on the other chain
your method was already covered on the other thread this post
that little amount can be replay first then replay the whole thing

I was thinking how about something like mixing coin in your own (single) address?
for e.g. I have an address with 5 unspents: u1, u2, u3, u4, u5, then make these transactions:
on BTC chain: send u1+u2+u3 back to its own address resulting u6btc
on bcc chain: send u1+u4+u5 back to its own address resulting u6bcc

similar transaction but different set, and must be done simultaneously at the same time
that would make whatever unspent on one network cannot be replayed on another chain
this is similar to spending on 2 chain to 2 different addresses
but instead, just one address is used and only half of unspent outputs needed to be spent on each chain
would this work? is there a flaw on my method?