Topic: Double-spending with 6 confirmations (Read 2854 times)

This is very simular to a speculation of how MyBitcoin, which required only 1 confirmation, was hacked with only 1 pre-mined block instead of 2 as required for a normal withholding attack: White Paper, section 11

Let's say the attacker has a decent 10 GH/s farm. It would only take him 3 months on average to solve 6 blocks. Doesn't sound practical to me.

3. The attacker solves 6 blocks so the transaction gets 6 confirmations.
...
Is it possible theoretically and practically? What could be used to prevent such an attack?

If the victim broadcasts tx then only the attacker receives it.

This idea came after reading https://bitcointalk.org/index.php?topic=114102.00:

Imagine that someone opened a lot of connections with multiple IPs to other nodes. Number of such connections so big that there are a lot of nodes connected only to the attacker. Let's assume the attacker attempts double-spending attack with the following scenario:

1. He chooses a victim and says that he will pay some bitcoins for something.
2. The attacker sends a transaction only to the victim, all other nodes know nothing about the transaction.
3. The attacker solves 6 blocks so the transaction gets 6 confirmations.
4. The victim sees the confirmations and complete its part of the deal.
5. While the attaker was solving his blocks the main blockchain got higher cumulative difficulty coz more than 6 blocks were solved. Even if the victim reconnects to other nodes it will see that non-legit transaction disappeared from the blockchain and the attacker still owns "spent" coins.

Is it possible theoretically and practically? What could be used to prevent such an attack?

You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network.  By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.

I use a similar method of watching block broadcasts to establish connections to most of the mining pools.

Now I create a transaction making a valid, large deposit into my target.  I do not broadcast this transaction but I add it to a block that I am attempting to mine.  I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.

Eventually, I succeed in creating a valid block.  I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target.  If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation.  The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.

I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control.  I also double-spend some of the inputs, sending the coins to myself.  The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.

If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.

If my block eventually "loses", then the deposit is invalidated.  If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.

+1 for vector76's hypothesis.

If mybitcoin was running bitcoin behind Tor, and had just one connection (through a Tor exit node) to the rest of the bitcoin network, then they'd be particularly susceptible to this 1-confirmation attack.

I need a solution for everyone, not only for myself. But thx anyway.

I need a solution for everyone, not only for myself. But thx anyway.

If your so worried about this issue, I would recommend running 8 Bitocin nodes in different servers around the world and have only your clients connect to those 8 Bitcoin nodes ONLY and not the hardcoded IP addresses in Bitcoin, It would be impossible for anyone to find out all those 8 server(Unless you told them which your an idiot if that became the ase). This way you surround your self with "Clean" nodes and only if all 8 Bitcoin nodes were cancerous would your Clients turn cancerous which is infeasible.

Well... Seems to me there is no a 100% solution to the problem.

As for generating blocks, today, even 10% of the total hashing power is a lot.

OK. But what to do if someone makes successful Cancer Nodes attack?

It's already happened:

Seems you are mistaken.

AFAIA the IRC bootstrap is no longer used so I still don't see how this could happen (unless the victim was running an old version of the client).

a lot of nodes connected almost exclusively to them, so they got all the notifications and forwarded them.

so it looked like all blocks came from them.

For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes.