A question on "double spend race attacks"

[ITCrowdFan]

Hey guys,

I'm still fairly new to the idea of bitcoins and wanted clarification on a few ideas.

In my research I found for merchants to prevent race attacks, they must

A) connect to a bunch of well-connected nodes.

B) Not accept incoming connections.

Can someone explain this is laymen's terms?
I know that every time a transaction is made a node connected to that device broadcasts it to the network, but I don't know how one would connect to more than one node or how setting up B would help the merchant.

For A I assume the large number of nodes the merchant connects to means an exponentially wider broadcast communication of which some nodes will already have the info of the attacker's 'legit' transaction to themselves, by which the node will then invalidate the conflicting transaction.

Thank you!

EDIT:
Does it also mean that the attacker would send the Fake Transaction to the merchant through 1 node whereas they would use a large number of nodes for the Real Transaction to himself for it to be confirmed before the Fake?

[Foxpup]

Does it also mean that the attacker would send the Fake Transaction to the merchant through 1 node whereas they would use a large number of nodes for the Real Transaction to himself for it to be confirmed before the Fake?

Exactly. A increases the chances that the merchant will find out about the what you've termed the "Real" transaction before it's too late to do anything about it (ie, they've already handed over the goods), while B makes it harder for the attacker to send the "Fake" transaction to the merchant and nobody else (since the attacker can't establish a direct network connection to the merchant).

[ITCrowdFan]

Another measure recommended is to avoid isolation, merchants must not relay the fake transaction.

I would have thought the opposite, wouldn't you want the transaction to be relayed so that nodes can identify that it is a duplicate node?

Thanks again!

[Peter R]

This isn't the answer to your question ITCrowdFan, and perhaps you already understand these details about the security of zero-confirm transactions, but in case it is helpful I thought I'd post it:



The double-spend problem for instant transactions, to most users and vendors, most of the time, is academic.  Let's consider how you could double-spend against a coffee shop here in Vancouver:

DOUBLE SPEND ATTEMPT #1: (fails)

1-A.  You walk up to the counter and ask for your coffee.  The sales girl generates the BitPay invoice, you scan the QR code, and press "send" on your iPhone.  The BitPay app picks up the transaction on the network in a fraction of a second, and the invoice suddenly says "PAID."  You grab your coffee and leave.

1-B.  But you're sneaky: you quickly run into your car where you've already generated a raw transaction with the same coins you used to pay for your coffee, but in this fraudulent transaction you instead send the coins to an address you control (you used the brainwallet.org "transactions" page) .  You broadcast this transaction using blockchain.info's pushtx service (https://blockchain.info/pushtx).  What you will realize is that by the time you got back to your car, the original transaction has already propagated across the network.  This means that nodes will not relay this new fraudulent transaction and miners will not add it to their memory pool since they know that these coins were already spent.  Double-spend attempt #1 fails.  

DOUBLE SPEND ATTEMPT #2: (fails)

2-A.  Discouraged by your failure, you head back to your evil lair where you continue your plot to get free coffee.

2-B.  You decide that you need to broadcast both transactions at roughly the same time in order to have a better chance of success.  You need to do this *inside* the coffee shop, but all you have access to while inside the store is your blockchain.info app for iPhone.  So, you jail-break your phone and hire an iOS expert to create you a custom double-spend app.  This app by design sends out the transaction to the coffee shop, but also sends out a transaction to an address that you control.

2-C.  So you order your coffee and test out your app.  But the BitPay invoice never says "paid."  When the sales girl checks at blockchain.info, she sees a big red "DOUBLE SPEND DETECTED" warning beside the transaction.

2-D.  You don't get your coffee and leave the store with everyone thinking that you are a thief.  

DOUBLE SPEND ATTEMPT #3: (succeeds once and a while)

3-A.  Back at the lair, you realize that your quest for free coffee is more difficult than you actually thought.  You call up some nefarious miner that controls 10% of the global hash power.  You tell him that when you give him the signal, he should add your fraudulent transaction to his memory pool of unconfirmed transactions.  You pay your iPhone hacker to modify your app to send the evil miner a special signal when you buy your coffee.

3-B.  You go to the coffee shop and buy your coffee.  Your new app sends the signal to the evil miner that you're in cahoots with.  The miner adds your fraudulent transaction, while the real transaction propagates across the network.

3-C.  Since the evil miner controls 10% of the global hash power, your coffee is free 10% of the time.  

3-D.  Finally, you succeed!  You also decide it is a lot less work to just pay for your coffee normally…

[btcpay86]

It has been solved by Bitcoin Core 0.9, isn't it ?

[Alley]

iPhone?

[Peter R]

iPhone?

LOL, I wrote that post in December.  HTML5 wallets are coming soon I hear...

[ITCrowdFan]

Thank you everyone for your replies,

The coffee shop analogy was very helpful.

But I am still confused on why merchants must not relay the fake transaction to prevent from an attack?

I thought the merchant want the fake transaction to broadcast so it can identify any other duplicates in the network?

[Peter R]

Thank you everyone for your replies,

The coffee shop analogy was very helpful.

But I am still confused on why merchants must not relay the fake transaction to prevent from an attack?

I thought the merchant want the fake transaction to broadcast so it can identify any other duplicates in the network?

By not relaying double spends, there's less chance these fraudulent transactions get confirmed.  The more widely you circulate the fraudulent transaction, the higher the chances that it gets included in a block.  All nodes are independent entities.  The can only trust what they see with their own eyes (so to speak), so they assume the first TX they see is the valid one.  If you relay a TX, you are basically saying "hey guys, this one looks good to me."  So you only want to relay the TX that you consider valid.  

Not relaying double spends also provides resistance against DoS attacks (otherwise you could flood the network with 1,000 TX variants spending the same coins).

[ITCrowdFan]

My initial thought was that the fraudulent transaction to the merchant had the chance to be a legitimate transaction if accepted by more nodes than the one sent by the attacker to himself.

Why is this wrong?

[Peter R]

My initial thought was that the fraudulent transaction to the merchant had the chance to be a legitimate transaction if accepted by more nodes than the one sent by the attacker to himself.

Why is this wrong?

I'm confused why you are calling the TX to the merchant the fraudulent one, but I think I follow what you are saying and yes you are basically right.  

The two TXs A and B will spread across the network.  All nodes will eventually have either TX A in their memory pool or TX B in their memory pool, simply based on what TX each particular node saw first.  There is no coordination beyond this simple "first TX is the legitimate one" algorithm.

The question now is what TX gets confirmed?  The answer is that it could be either!  It is a random process.  But we can say that if the nodes that accepted TX A control 75% of the hash power, that the probability that TX A gets mined is 75%.

A merchant with a well-connected listening node will know that two TX variants exist, so he won't get scammed, but he has no way to know which TX will get confirmed until the next block is found.  

Does this answer your question?

[which2say]

It has solved the Bitcoin core 0.9 emerging problem?

[ITCrowdFan]

Peter R: Yes thank you!


An article says that merchants shouldn't relay any transactions in order to avoid being isolated.

Can anyone elaborate on this please?

And how are double spends detected?

[btcpay86]

It has solved the Bitcoin core 0.9 emerging problem?

[amspir]

DOUBLE SPEND ATTEMPT #3: (succeeds once and a while)

3-A.  Back at the lair, you realize that your quest for free coffee is more difficult than you actually thought.  You call up some nefarious miner that controls 10% of the global hash power.  You tell him that when you give him the signal, he should add your fraudulent transaction to his memory pool of unconfirmed transactions.  You pay your iPhone hacker to modify your app to send the evil miner a special signal when you buy your coffee.

3-B.  You go to the coffee shop and buy your coffee.  Your new app sends the signal to the evil miner that you're in cahoots with.  The miner adds your fraudulent transaction, while the real transaction propagates across the network.

3-C.  Since the evil miner controls 10% of the global hash power, your coffee is free 10% of the time.  

3-D.  Finally, you succeed!  You also decide it is a lot less work to just pay for your coffee normally…

Currently 10% of the network would require 4,000 TH/s, and with modern rigs, you would pay around $3000 per TH/s.   Evil miner would need $12 million of equipment to provide this service if I did my math right. 

[Brangdon]

Currently 10% of the network would require 4,000 TH/s, and with modern rigs, you would pay around $3000 per TH/s.   Evil miner would need $12 million of equipment to provide this service if I did my math right. 

The rig should pay for itself in honest transaction fees and block rewards. Revenue from dishonest double-spending attempts would be a bonus.

The miner risks getting a reputation for dishonesty. I don't know what the consequences of that would be. Do miners get blacklisted?

As for $12m, that figure appears to be in the right ballpark. This Ars Technica article talks of a rig costing $3-5m that has around 5.6%. He reckons it has paid for itself many times over. I'm guessing he, personally, would not approve of his gear being used for dishonest transactions, but I suppose he might eventually have company employees junior enough to be bribed or coerced into it, yet senior enough to get it done. The main problem is that it's not worth it for a few low-value transactions, and high-value ones can usually wait for confirmations and/or know their customers.

Getting 51% would only cost $60m, so it's within reach for a great many people and institutions.

[RawDog]

3-D.  Finally, you succeed!  You also decide it is a lot less work to just pay for your coffee normally…

Good story.  I like this whole thing except the explanation about 'a lot less work to just pay...'.  This might be true for coffee - but what about Lamborghinis?  

[Agent99]

Found very good answers to the same questions I were interested too.

[binaryFate]

3-D.  Finally, you succeed!  You also decide it is a lot less work to just pay for your coffee normally…

Good story.  I like this whole thing except the explanation about 'a lot less work to just pay...'.  This might be true for coffee - but what about Lamborghinis?  

Nobody would be mad enough to sell Lamborghinis with 0 confirmation. All this discussion is about 0-conf transactions.
I guess everybody can afford to wait 6 confirmations (~1h) when buying a car.

[Peter R]

The rig should pay for itself in honest transaction fees and block rewards. Revenue from dishonest double-spending attempts would be a bonus.

The miner risks getting a reputation for dishonesty. I don't know what the consequences of that would be. Do miners get blacklisted?

Yes, one could potentially earn a profit operating an out-of-band double-spending service.  (Note that this only applies to zero-confirm transactions.  There is a very large cost associated with attempting to double spend a 1-confirm transaction.)

We discussed the ethics of providing such services for a fee here: https://bitcointalk.org/index.php?topic=502571.0

Right now the network is quite well behaved.  I would accept up to $3000 of value in a face-to-face zero-confirm transaction, and probably up to $400 remotely.  For larger values, I would wait for 1 to several confirmations, depending on the values involved.  

We don't yet know how the network will behave in the future, as we don't yet know the costs associated with the loss of reputation associated with providing such services.  We do know however, that the bitcoin economy will suffer aggregate losses due to zero-confirm fraud no greater than:

       (% losses on zero confirm TXs) <=
  (% of TXs where double spending is attempted) x (% of hash power that accepts out-of-band double-spends for a fee)

If we assume that 10% of the hash power is willingly complicit in facilitating double-spending, and consumers in aggregate attempt to double spend 2% of all transactions, then we would expect losses no greater than (0.1) x (0.02) = 0.2%.  This would be already much better than the losses due to Visa, MasterCard or PayPal fraud.  For 1+ confirms, the losses due to double spending would be almost non-existant.  

Lastly, any merchant is free to require 1, 2, 3 + confirms if the expected losses are too high.

There is no official way to blacklist a miner, but the miner's peers can attempt to punish miners by ignoring them.  It is also not clear if miners would be deterred from offering such services if such services were deemed fraudulent by law enforcement.