Is it possible to detect double spending in the > 50% network takeover scenario?

[ShadowOfHarbringer]

Hello,

I was wondering if it would be possible to detect double spent bitcoins in the attack scenario where attacker has more than 50% of whole bitcoin network processing power ?

By "detection" i also mean situations when we know which nodes of the network spent the same coins twice without knowing which one is "cheater" and which one "honest".

[1715167854]

1715167854

[theymos]

You could probably distinguish original transactions from double-spent ones if the attacker is rewriting blocks that are more than one block deep. You can't be sure for transactions with only 0 or 1 confirmations, since this kind of "split opinion" could occur naturally.

If the legitimate network regains control and it's clear that the main block chain is full of double-spends, the network could start building on some shorter chain before the event to reverse the double-spends. This would probably also reverse some legitimate transactions, though.

Just detecting that someone is messing with the network is much easier, and I wouldn't be surprised if Bitcoin does try to detect this at some point.

[theymos]

If I send you 100 BTC's, from wallet abc to your efg, what split would occur naturally? If the network were split, potentially both could have the same spend... right? But they would be to the same wallet.

If you double-spend, then both recipients will get transactions with 0 confirmations. The network isn't sure yet which one came first, since the simple TCP network can't be counted on. Normally after one block the network will decide which one is valid. However, it is possible (though unlikely) for two blocks containing different versions of the transaction to be generated at the same time, in which case it would take another block to figure out which one is valid. (It's possible for this to happen a second time, but too unlikely to think about.)

So a detection mechanism could say, "This new block would replace a block that is 5 blocks deep in the main chain. Any transactions in that chain that conflict with transactions in the main chain are likely to be double-spends." It could not say (with reliable accuracy), "This new block is now the latest block in the main chain. However, one of its transactions conflicts with one that I received via the TCP network first, so the block's version must be a double-spend."

[theymos]

What I'm asking, is can the client know that these two 0 transactions exist? If that is possible, could the client not allow the transaction to be available for spend until like 10 transactions?

Yes. It's a good idea. If a transaction that conflicts with yours is spotted through the network or in a block (even a block in a shorter chain), then remove your version from all RPC listings and display it specially in the UI. The existence of any conflicting transaction means that the person who sent you the transaction is trying to defraud you.

[ShadowOfHarbringer]

Thank for your answers, I think i get it now.

[ShadowOfHarbringer]

I think that the hosts which have a lot of double spents should be added to client's ban list.
First, a temporary ban list, and then a permament one.

If a host improves his behavior, it may be removed from the temporary ban list. But if it keeps double spending, then it should be added to the permament one.

To preserve anonymity, hosts could be indentified by public & private key or digital signature system or whatever.
Also, the clients could communicate between each other to exchange their ban lists. But only if the particular clients trust each other. Some trust system/network could be developed for that.

(Just thinking loud here, don't mind me).

[FreeMoney]

In the >50% attack. A transaction can get an arbitrary number of confirms and then eventually be undone by the attacker making a longer chain that doesn't contain the transaction, then he can spend it again at will any time in the future.

So no, you can't tell until the transaction disappears at which point it will be too late.