Fallback double spend protection during forks

[jevon]

I think the OKPAY double spend during the fork could have been prevented if the software did not ignore double spends it receives. The double spend transaction was not a secret. It was announced to the network to get into miner's pools. The OKPAY server probably received the double spend from at least one of its peers, but the software ignored it. Instead, it should really put the payment in a -1 conf penalty box for several 100 blocks until any possible fork or blockchain problem will have been sorted out. A caught double spend is nothing to take lightly.

I wrote a dspend alert message proposal here https://github.com/bitcoin/bitcoin/issues/1034, but as BlueMatt suggests, even without a dspend alert, we can have 95% of the benefit just by taking appropriate notice of double spends we already see. If a node has 20 connections, then any double spend reaching more than 5% of the network will probably hit one of those 20 connections.

[1715120285]

1715120285

[1715120285]

1715120285

[1715120285]

1715120285

[paraipan]

I think the OKPAY double spend during the fork could have been prevented if the software did not ignore double spends it receives. The double spend transaction was not a secret. It was announced to the network to get into miner's pools. The OKPAY server probably received the double spend from at least one of its peers, but the software ignored it. Instead, it should really put the payment in a -1 conf penalty box for several 100 blocks until any possible fork or blockchain problem will have been sorted out. A caught double spend is nothing to take lightly.

I wrote a dspend alert message proposal here https://github.com/bitcoin/bitcoin/issues/1034, but as BlueMatt suggests, even without a dspend alert, we can have 95% of the benefit just by taking appropriate notice of double spends we already see. If a node has 20 connections, then any double spend reaching more than 5% of the network will probably hit one of those 20 connections.

It was practically unavoidable because transaction had more than 6 confirms in the +0.8 blockchain, which was later dumped by the miners. A better strategy would have been to halt operations right when the bitcoin network alert was issued. Delaying the funds to "double spender" based on that would have been rendered the attack useless.

[jevon]

It was practically unavoidable because transaction had more than 6 confirms in the +0.8 blockchain, which was later dumped by the miners.

But this would have avoided it. It would have detected the existence of a double spend seen on the network and locked the transaction for several days, like 500 blocks.

Once you know a double spend exists of your payment, it is a dangerous payment and should be held for a long time before accepting it.

[paraipan]

It was practically unavoidable because transaction had more than 6 confirms in the +0.8 blockchain, which was later dumped by the miners.

But this would have avoided it. It would have detected the existence of a double spend seen on the network and locked the transaction for several days, like 500 blocks.

Once you know a double spend exists of your payment, it is a dangerous payment and should be held for a long time before accepting it.

I don't think you really understand the issue here. This wasn't a normal double-spend that you can avoid like you say, the situation here is more like when someone sends bitcoins, waits for the 6 confirms then withdraws cash from the online wallet or exchange with the purpose of double spending them in a different blockchain fork. He just have wait for the network to reorganize the blockchain, based on consensus, and then he will be able to use the same coins with other wallets or services, because the original spend was confirmed only in the 30-40 blockchain fork that was left behind, hence no spending occurred and the wallet service is left holding the bag.

[jevon]

Crap, you're right, in the OKPAY case the first transaction took so long to get into the slow 0.7 fork, the double spend didn't need to be sent until 3 hours later. So this would not have prevented the specific OKPAY case, although it would have alerted them as soon as possible.

I think it still would prevent the typical case where someone fires double spends into each fork at the same time, which is what you'd normally have to do to exploit a fork, especially if the dominant fork ends up winning.

[falschgeld]

For a beneficiary (merchant/exchange/whatever), the safest thing to do in case of a fork would be to require that transactions clear in both blockchains until it is clear which blockchain wins; However, this gets a bit difficult if either blockchain happens to be slow.

However, I think that it's a gross negligence not to watch out for any double-spending attacks. I think that the risk of double-spending attacks could be mitigated substantially if any client which sees a double-spending attack would warn the beneficiary. This would have to be done outside the normal broadcasting system because 1) nobody exept the beneficiary needs to receive the warning - so we don't need to flood anybody's network connection with this info. 2) Each client is supposed to bury the wrong transaction by not rebroadcasting it. REbroadcasting it anyway could encourage miners to include it in their blocks which is what we want to avoid.

[TierNolan]

For a beneficiary (merchant/exchange/whatever), the safest thing to do in case of a fork would be to require that transactions clear in both blockchains until it is clear which blockchain wins; However, this gets a bit difficult if either blockchain happens to be slow.

Sounds good.  The client should be monitoring both chains anyway.

A transaction is not confirmed unless it is included in forks that are collectively getting at least 90% of the hashing power.

The nice thing about that is that a fork doesn't freeze the network while it is being worked on.