Double-spending with 6 confirmations

[Come-from-Beyond]

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?

[CIYAM]

2. The attacker sends a transaction only to the victim, all other nodes know nothing about the transaction.

Unless the "victim" is running some non-standard software or have been configured specifically to not broadcast tx's this should not be possible (unless you are saying the attacker owns the victims internet connection).

Actually even if they did own the victims internet connection they would still have to be rather amazing to be able to complete the 6 confirmations within one hour.

[Come-from-Beyond]

2. The attacker sends a transaction only to the victim, all other nodes know nothing about the transaction.

Unless the "victim" is running some non-standard software or have been configured specifically to not broadcast tx's this should not be possible (unless you are saying the attacker owns the victims internet connection).

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

[CIYAM]

2. The attacker sends a transaction only to the victim, all other nodes know nothing about the transaction.

Unless the "victim" is running some non-standard software or have been configured specifically to not broadcast tx's this should not be possible (unless you are saying the attacker owns the victims internet connection).

If the victim broadcasts tx then the attacker receives it.

I thought that your point was that other nodes know nothing about the transaction - how has the attacker stopped that from occurring (i.e. the victim won't only send the tx to the attacker)?

[Come-from-Beyond]

I thought that your point was that other nodes know nothing about the transaction - how has the attacker stopped that from occurring?

Does client use P2P broadcasting (with explicit connection) or it's IP broadcasting to the whole Internet? If it's P2P, then tx won't be really broadcasted, coz only the attacker will receive it.

[CIYAM]

Sorry - I edited the last post a bit late - as far as I know the standard client will send the tx to all the connections it has (nothing to do with who you are sending actual bitcoin to and in all likelihood your attacker would not even be one of those connections).

Is the point that the attacker is somehow the only connection the victim has to the P2P network?

[Come-from-Beyond]

Actually even if they did own the victims internet connection they would still have to be rather amazing to be able to complete the 6 confirmations within one hour.

If there is only a bot on victim's side it won't care if it takes 10 hours for 6 confirmations.

As far as I know the standard client will send the tx to all the connections it has (nothing to do with who you are sending actual bitcoin to and in all likelihood your attacker would not even be one of those connections).

Is the point that the attacker is somehow the only connection the victim has to the P2P network?

Yes. The attacker is the only who has connections to the victim.

[joecascio]

I believe the servers forward the transaction to other servers. (Can someone verify this?). The client can't control who the server forwards the transaction to, therefore the assumption you base the exploit on would not be valid.

[CIYAM]

Yes. The attacker is the only who has connections to the victim.

And how exactly does the attacker control that (without having first hacked the victim's computer)?

[Come-from-Beyond]

Yes. The attacker is the only who has connections to the victim.

And how exactly does the attacker control that (without having first hacked the victim's computer)?

https://en.bitcoin.it/wiki/Weaknesses:

It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.
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. This state can be exploited in (at least) the following ways:
The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.
Looking for suspiciously low network hash-rates may help prevent the second one.

Cancer nodes attack is implemented right now as it's said in the thread I made a link to.

[CIYAM]

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.

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

[Come-from-Beyond]

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.

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

It's already happened:

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.

[CIYAM]

It's already happened:

I don't think that is quite correct.

Seems you are mistaken.

Well I was wondering how long it would take for people to notice. It's me

And no I am not putting lots of hashing power to the network, notice that it just says "relayed by" and not "mined by". I'm performing some measurements, paper is due in a few weeks.

[Come-from-Beyond]

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

[Yurock]

Theoretically, it is possible. The difficulties are:

• making sure that the victim is not connected to any honest nodes,
• generating blocks.

Even though IRC is no longer used by default, the node has to obtain peers' addresses somehow. And it is possible to interfere with this process. If the target node accepts tcp connections, an attacker can open many connections with the node as soon as it starts, and feed it with addresses of nodes controlled by the attacker. This way chances of the target node to connect to any honest node are significantly lower.

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

[CIYAM]

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

I think if someone has complete control over a potential victim's computer then just stealing their wallet (or installing a trojan that changes the payment address when you send BTC) would probably be much easier than this idea so I wouldn't really be too worried about this "cancer node" scenario (although keeping the client up-to-date is important).

[Come-from-Beyond]

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

Today. But what about when BFL ships ASICs?

Well... Seems to me there is no a 100% solution to the problem. Thx for the replies, guys.

[Yurock]

Solution: Make sure your nodes are always connected to at least one honest node. Make an agreement with miners, they are always connected to the main network, otherwise they lose money. Make encrypted channels between your own nodes and some miners. Monitor these connections. This way, even if an attacker will be controlling your internet connection, it will not go unnoticed.

As technology improves, total hashing power increases. 10% will likely always be a lot.

[MatthewLM]

I'm looking to create a secure connection with the client I'm making. So the chance of an attack using this method would be impossible. The most an attacker could therefore do is prevent someone using bitcoin if the attacker has control over the internet connection.

[Stephen Gornick]

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

As always, the level of security needed should be proportionate to the risk.

If a merchant is going to run their own node, there are two recommendations:  Disable incoming transactions, and have an explicit connection to a well known, trusted node. 

That's the recommendation for the merchant selling donuts.

For a merchant that has a higher volume (.e.g, ecommerce site or exchange, etc with larger volumes), it would be prudent to have listening nodes to confirm that your longest chain is the same as the rest of the world's longest chain.

There are situations where bitcoin is not an appropriate payment method.  Accepting Bitcoin payments requires relatively continuous network communications:
 - http://bitcointalk.org/index.php?topic=106302.0

Certainly though, with there existing these attack vectors, there will be poorly configured merchants out there and there will be thefts on merchants accepting payment with 0/unconfirmed.

But to see losses on confirmed transactions would only occur if you didn't follow the basic recommendations.