Quote from: Come-from-Beyond on October 06, 2012, 12:13:43 PM

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?

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

Quote from: vector76 on August 17, 2011, 05:37:56 PM

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.

Quote from: Gavin Andresen on August 17, 2011, 05:48:26 PM

+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.