Two Bitcoins at the Price of One

[meanig]

I came across this paper on Twitter

"Two Bitcoins at (sic) the Price of One? Double Spending attacks on Fast Payments in Bitcoin."

http://eprint.iacr.org/2012/248.pdf

Their strategy is to cheaply double spend a coin by using friendly hosts to spread the malicious transaction. They've shown it to work without being detected for approximately 10 seconds, enough time they believe for you to run away from Starbucks with your coffee.

Is this really a problem for fast transactions? I've used fast transactions (Bit-Pay, Coindl and Bitcointorrentz) and they already cautiously wait for around 10 seconds before confirming payment.

[SgtSpike]

Any service that uses 0-conf is usually for cheap, low-dollar goods.  Businesses take the same risk when they sell goods that might potentially be bought with counterfeit dollars, a stolen credit card, or a bad check.  Bad funds received are just a part of doing business.

It's not likely that many people will go through the trouble of doing a 0-conf double spend, and those that do will need to cover their tracks well.  It can be days before a business knows that they received a bad check - 10 seconds means the criminal needs to get out of a physical location quickly!  For digital downloads and such, if enough people do it, then they'll simply wait a bit longer to give away the download link, or whatever it is they are waiting on.

[DeathAndTaxes]

The 0-confirm double spend is something which has been known and studies for some time.

That being said a 10 sec window for real world face to face transactions is just asinine.

Counter experiment.
Go to starbucks, order, swipe your credit card.
START STOPWATCH
wait for coffee ... wait .... wait ... get coffee ... walk to door ... get in car ... drive out of line of site.
STOP STOP WATCH

I am 99% certain the elapsed time is going to be >10 sec.

There are methods to reduce (but likely never eliminate) the fraud risk of 0-confirm double spends.  That being said no payment system is without risk.

Cash:  counterfeit bills, theft, bank processing fees (which is why stores "generously" allow cashback)
Credit cards: stolen cards, friendly fraud,  never ending cut to VISA/MC.

The goal isn't to reduce fraud/theft/loss to 0%.  Doing that likely will drive away consumers.  The goal is to reduce the COST OF PROCESSING transactions which includes everything from employee training to fraud to bank fees to infrastructure/logistics.  

[Blazr]

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.

[SgtSpike]

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.

And there you go!  An intermediary processor that takes the risk of double-spends in exchange for a fee.

[Fuzzy]

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.

And there you go!  An intermediary processor that takes the risk of double-spends in exchange for a fee.

Gotta love bitcoin 

[Stephen Gornick]

I'm still reading it but it was already a recommendation that the merchant not allow incoming network traffic (and disable UPnP) and to explicitly connect only to well-known nodes, preferably the mining pools.

I don't see anything in the report yet that indicates they tested using this configuration.

[giszmo]

The suggested double spend alert would be hard to do as it would open doors for DOS attacks.

I see only green addresses or to a degree well connected clients to do instant payment for now.

In the end I wouldn't worry too much about brick and mortar fraud as here the client has a face to loose within 10s. It would just be too risky to actually see my double spend attempt being identified as such even within 10s.

[SgtSpike]

The suggested double spend alert would be hard to do as it would open doors for DOS attacks.

I see only green addresses or to a degree well connected clients to do instant payment for now.

In the end I wouldn't worry too much about brick and mortar fraud as here the client has a face to loose within 10s. It would just be too risky to actually see my double spend attempt being identified as such even within 10s.

Exactly.  You may as well just run out of the establishment with the goods in hand.  It'd be the same result either way.

[Stephen Gornick]

Here were recommendations for merchants not considered by these researchers:

A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

- Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
- Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required

 - http://bitcoin.stackexchange.com/questions/2622#2625

[Stephen Gornick]

Here were recommendations for merchants not considered by these researchers:

A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

- Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
- Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required

 - http://bitcoin.stackexchange.com/questions/2622#2625

The method used in the research paper relied on the ability to know the IP address for the vendor and to directly connect to that vendor's node.  (which presumes that the vendor's firewall has UPnP enabled and/or the port for Bitcoin is accessible from the outside, such as when the network's firewall has port forwarding enabled and is routing that traffic to the host that the Bitcoin node runs from.)

And shock of all shocks, a race attack was successful in nearly every attempt.

[REF]

http://zipconf.com

This will be the solution for 0 confirmation transactions. This service will only work with exchanges at the moment, but its only a matter of time before BitPay or coinDL use a similar system to protect them from double-spends.

so many great bitcoin start ups Iv never heard of. thanks for the link

[eldentyrell]

I came across this paper on Twitter

I doubt you'll come across it in a peer-reviewed venue.

Is this really a problem for fast transactions?

No.  It's a problem for 0-confirm transactions, which has been obvious since the original Bitcoin paper.

"Fast" transactions can mean lots of things.  Sounds like the "researchers" who wrote this paper concocted the new term so they could flaunt the problems it has.  Pointing out the flaws in "I didn't wait for confirmations and got hacked" doesn't have quite the same ring to it.

The authors need to re-title their paper "here is yet another reason you shouldn't accept 0-confirmation payment for non-recourse transactions".

[FreeMoney]

I came across this paper on Twitter

I doubt you'll come across it in a peer-reviewed venue.

Is this really a problem for fast transactions?

No.  It's a problem for 0-confirm transactions, which has been obvious since the original Bitcoin paper.

"Fast" transactions can mean lots of things.  Sounds like the "researchers" who wrote this paper concocted the new term so they could flaunt the problems it has.  Pointing out the flaws in "I didn't wait for confirmations and got hacked" doesn't have quite the same ring to it.

The authors need to re-title their paper "here is yet another reason you shouldn't accept 0-confirmation payment for non-recourse transactions".

I didn't read it all, but I'd suggest a title of "wait 30 seconds and you're in the clear"

[eldentyrell]

I didn't read it all, but I'd suggest a title of "wait 30 seconds and you're in the clear"

Yes, waiting 29.9 seconds is terribly dangerous.

[MoonShadow]

The ten second window has been (intuitively) known among most of the old salts of this forum for two or three years.  This might be the first time that it was confirmed with any kind of experiment, or perhaps not.  Many methods of reducing exposure risk to a 0/conf race attack have been proposed, but none yet implimented simply because they don't have any current demand in the marketplace.  I've personally suggested more than one method, myself.  Furthermore, since there are so many different tactics at reducing said exposure, there is no practical way that an attacker could know in advance which method, if any, his mark may be employing.  The simplest method of all would be to simply delay the completion of the transaction for ten seconds.  How often have you seen an electronic check or a cc transaction take longer than that?

[PawShaker]

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful. The only problem I can see, is that overspending a coin N times may generate O(N^2) alerts. Hence generation and propagation of alerts must be a little bit smarter than authors of the paper envisioned. Before rising or propagating and alert, nodes must search their cache of alerts not only for an exact match, but also for any other alert that contains transactions with the same inputs.

Over all, it is a valuable food for thought.

[MoonShadow]

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

[FreeMoney]

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

Seems obvious now but I'd completely overlooked it. I was thinking that you could wait and see if you hear another with the same inputs.

[PawShaker]

I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.

If you read it carefully, the proposed alert mechanism may be very useful.

I read the suggestions presented in the paper, and I've personally proposed both over a year ago.  Looks to me like someone has been lurking the forum and turned that into a school project.  The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate.  Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all.  So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet.  Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network.  If they match & are good, then a (successful) race attack is very unlikely.  If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved.

This method doesn't require that a special service or a distant node owned by the vendor exist.

Why not to take it a step further and simply do not propagate a transaction message if receiving address belongs to the vendor/owner of the node. This effectively turns all vendor’s peers into listening posts.

It is also hard to judge which node is the farthest. On internet distance can be quite tricky: ping time, trace hoops, BitCoin hoops, geographic distance. While it is hard to find farthest one, it is quite easy to locate peers which are close to each other, the difference in timing of messages from two close nodes will have low variation.