2012-09-24 ethz.ch - Better security for the internet currency Bitcoin

[julz]

Swiss Federal Institute of Technology Zurich.

Better security for the internet currency Bitcoin

Felix Würsten
2012-09-24


Paper 'Two Bitcoins at the Price of One? Double-Spending Attacks on
Fast Payments in Bitcoin'

Elli Androulaki
Ghassan O. Karame
Srdjan Capkun
http://people.scs.carleton.ca/~clark/biblio/bitcoin/Karame%202012.pdf


The internet currency Bitcoin was created in 2009. It should offer the same advantages as cash. The new electronic currency has an increasing number of supporters. But ETH-researchers found out, that there is a securitiy problem. They also have a suggestion, how this problem could be solved.
...
Together with Ghassan Karame and Srdjan Capkun, Elli Androulaki, a postdoc at the Institute of Information Security, managed to demon­strate that there is actually a security loophole here, even if it has never been exploited in concrete daily life. With an elaborate configuration, the buyer can actually spend his electronic coins twice: first, he buys the goods he desires; then he transfers the same amount to his own account.

The problem as far as I can see is that of double-spending attacks against vendors who accept zero-confirmation transactions.
I've seen this (or very similar) discussed around the forums before - so the wording of this article seems a little misleading to me in that it seems to imply it's a new discovery.

This paper looks like an interesting technical analysis of this (IMO well-known) issue, with some useful figures and will presumably be helpful for those implementing zero-conf  risk-reduction strategies
e.g

Our experiments in Section 4.4 show that the average
time for a peer to receive both TRA and TRV is approximately 3.354 seconds

would seem to suggest that a point of sale system could subscribe to some sort of double-spending monitoring system which might give the all-clear after some reasonable small wait time (I'm guessing somewhere around 5 seconds might be reasonable in terms of risk vs convenience?)

[hamdi]

those accepting zero-conf. payments mostly offer downloads

[Coinabul]

I saw this article and was not impressed :/ Might just be because they're being vague.

[dissipate]

Zero confirmation double spending attacks have been known about for a long time. I'm not sure what new information they have on this (if any at all). There is a fairly simple solution to zero confirmation spends: https://en.bitcoin.it/wiki/Green_address.

[Stephen Gornick]

How did this research published months ago end up back in the news?

Anyways, they are claiming near 100% success in double spending using a race attack under a configuration that is not recommended for merchants.

Following the basic recommendations for merchants (don't allow incoming transactions, explicitly connect to well-connected nodes), the chance of a race attack becoming successful drops to a level that can be managed, if not eliminated completely.

 - http://bitcointalk.org/index.php?topic=79090.0;all


There is no protection against a Finney attack except for that attack being so expensive to carry out (over $1 per second to hold a block while trying to carry out the attack.)

That being said, no traders have reported losing funds to a double spend resulting from a race attack.

A coin changer at the laundry that takes bitcoins -- sure, that's vulnerable to the race attack.  But selling coffee on 0/unconfirmed and most other types of bricks and mortar commerce have little to fear from accepting bitcoins as payment before the transactions have any confirmations.

Here's more regarding recommendattions:

 - http://bitcointalk.org/index.php?topic=106026.0

[Stephen Gornick]

This reads as a deliberately misleading article,

In order to offer a solution to a problem, you need to show that there really is a problem that needs to be solved.  

If there's no flaw, then what need is there for a solution?  So for the purposes of their research they make the assertion that there exists this rack attack problem.

Now because they are correct that one or more configurations will leave Bitcoin vulnerable as they describe, they used one as an example and ran with it.   Their solution will lessen the double spending race attack regardless of whether the client is configured correctly or not, therefore it is beneficial work they did, but merchants have alternatives that work nearly as well which they didn't reveal (configure with no incoming connections, and explicitly connect to well-known nodes).

[Mike Hearn]

How did this research published months ago end up back in the news?

It's an ETH specific newsletter, so it's natural that it's both rare and reporting on the research done at ETH.

[lonelyminer (Peter Šurda)]

I read this research article a while ago. Basically, the problem is that when a node receives a transaction and later a conflicting transaction, it will ignore the latter one without any indication to the user, so it will appear as if the original transaction was still valid. Then when the other transaction is put into a block, the payment "suddenly" reverses. Stephen already pointed out that this requires a setup type that is not recommended, and I think that this can also be worked around on the implementation level. Maybe it can delay processing if it detects a double spend attack, so the merchant will see the incoming payment vanish after receiving the second transaction. That's not perfect but makes detection quicker.

[Serith]

Authors arguing that they have cost effective solution for the problem by using alert messaging system to inform network about double spend attempts to make it easier for a merchant to accept zero-confirmation transactions.

Given our findings, an efficient countermeasure to combat double-spending on fast Bitcoin payments would be for Bitcoin peers to propagate alerts whenever they receive two or more transactions that share common inputs and different outputs

[phatsphere]

my feeling is, the main client should just show a red warning, iff there is another unconfirmed transaction that looks like a double spend (e.g. number of identical input tx is >= 1, or maybe there is a better way to do this)