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?

[1714750531]

1714750531

[1714750531]

1714750531

[1714750531]

1714750531

[1714750531]

1714750531

[1714750531]

1714750531

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

[Xenland]

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.

[Come-from-Beyond]

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.

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

[DeathAndTaxes]

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

One option would be have the client allow users to set a trusted node.   For example if a user trusted his friend, blockchain.info, his mining pool, or MtGox he could set that as a trusted node and it would always attempt that connection first.  Currently that can be done from the config but an easy to use GUI would be a method to improve security.

A more robust solution would be an (optional) system where nodes were strongly authenticated using a public/private key type system.  This would also prevent MITM type attacks where attacker intercepts communication from "good nodes" and relays false data to victim.   Say you trust me and you have my public key.  When you bootstrap you could request the nodes that you connect to to search for my node and relay that.  An attacker couldn't impersonate my node without my private key.  An attacker could still prevent communication however you client could alert you (or even be programmed to not accept any data which doesn't come from at least one trusted node).

Taking it a step further a WOT type system could be put in place.  I trust come-from-behind so I mark his node as trusted (digitally signed w/ my private key).   A new node comes online and it doesn't trust cfb but it does trust me.  Even if my node if offline the indirect trust could be used for the node to connect to cfb in a semi-trusted manner.

[Come-from-Beyond]

Seems to be a good idea. I'll think about it.

[Xenland]

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.

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

Well then host 1000 Clean bitcoin nodes or at least host more Bitcoin nodes around the world more than cancer nodes.  Did anyone mention to you that its near impossible to know if you've taken over a Bitcoin client(Unless you have some kind of control over the computer it self to query the Bitcoin client for the connected nodes)? I was gritty about this issue my self a year back, The only answer is that its very infeasible for this to happen unless the incentive is great (You know your friend has a million bitcoins and leaves his computer open) but I'd imagine when Bitcoin goes mainstream more then half the population will not know how, or even want to run their own Bitcoin nodes to leave their own computer security to their self and bitting their teeth all day wondering if their Bitcoins are stolen yet or if they "Did it right", they will rely on companies called Bitcoin banks or a hardware device that thwarts these kind of attacks).

[Serith]

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

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.

[Realpra]

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

That's an isolation attack, its pretty well known, but rather hard to execute.

Additionally you would likely only be able to scam small merchants for small amounts for all your effort.

I'm not worried about this at all.

[Syke]

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?

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.

[kjj]

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?

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.

The 6 blocks need to be consecutive and current, not random.

[gmaxwell]

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

As an aside, many people searched and none could find an orphaned block in their storage (bitcoin stores all blocks lost in reorgs) which contained a double spend against the main chain, making their claimed attack vector very unlikely. Moreover they refused to provide a copy of their blockchain file, which would have conclusively proved the attack. In light of this I believe it's far more likely that they gambled away or just outright stole the funds.

In any case, Bitcoin "takes advantage of the nature of information being easy to spread but hard to stifle"— you only need one honest connection to resist this kind of attack, and the attack can't be performed against reasonable client software that enforces a reasonable number of confirmations without a considerable cost in producing doomed blocks.