Better security for the internet currency Bitcoin???

[BitCoinBarter]

I assume others have seen this: http://www.ethlife.ethz.ch/archive_articles/120924_Neuer_Globe_Bitcoin_fw/index_EN

Can someone direct me to the thread or threads that discuss this?

[1715348728]

1715348728

[1715348728]

1715348728

[Revalin]

The article just talks about double spending which is a problem older than Bitcoin.

https://en.bitcoin.it/wiki/Double-spending

I don't see any link to the actual research so I can't really say if there's anything new.

[julz]

Press section: https://bitcointalk.org/index.php?topic=112328.0

[Mike Hearn]

Stefan and I met with these researchers a few months ago in Zurich and discussed it with them. The attack is real and was known about for a long time before this paper, but they did some good digging into the details. It's difficult to exploit, I wouldn't lose too much sleep over it right now (there are no pre-made tools you can download to pull it off or anything like that).

The fix has been discussed somewhat and I think Gavin now has a design he's comfortable with in mind. The code wasn't written yet.

[BitCoinBarter]

I don't see any link to the actual research so I can't really say if there's anything new.

I noticed that. That made me think that it is Fear, Uncertainty and Doubt (FUD).

[gmaxwell]

Stefan and I met with these researchers a few months ago in Zurich and discussed it with them. The attack is real and was known about for a long time before this paper, but they did some good digging into the details. It's difficult to exploit, I wouldn't lose too much sleep over it right now (there are no pre-made tools you can download to pull it off or anything like that).
The fix has been discussed somewhat and I think Gavin now has a design he's comfortable with in mind. The code wasn't written yet.

"Real" well, it's real if you don't follow the advice widely propagated and embedded into the reference client: Don't accept zero confirmation transactions, unless you have some way of being secure against reversal externally to bitcoin.  They even underestimate the risk of it because they were unaware of how easy it is to buy hash-power to perform finney attacks now (and the cost is only going down, esp. with the upcoming reward halving).

I disagree with calling improved double-spend notices _a fix_, as finney attacks _can't_ be fixed. And while double-spend notification could be greatly improved, I don't think it matters because all that does is create false security against finney attacks. The fix that that came out of this was removing all the text on the bitcoin wiki that you added which suggested that accepting zero-confirmations were safe so long as you listened for conflicts... text I don't think most people knew was there until the paper pointed it out.

[Serith]

Stefan and I met with these researchers a few months ago in Zurich and discussed it with them. The attack is real and was known about for a long time before this paper, but they did some good digging into the details. It's difficult to exploit, I wouldn't lose too much sleep over it right now (there are no pre-made tools you can download to pull it off or anything like that).
The fix has been discussed somewhat and I think Gavin now has a design he's comfortable with in mind. The code wasn't written yet.

"Real" well, it's real if you don't follow the advice widely propagated and embedded into the reference client: Don't accept zero confirmation transactions, unless you have some way of being secure against reversal externally to bitcoin.  They even underestimate the risk of it because they were unaware of how easy it is to buy hash-power to perform finney attacks now (and the cost is only going down, esp. with the upcoming reward halving).

I disagree with calling improved double-spend notices _a fix_, as finny attacks _can't_ be fixed. And while double-spend notification could be greatly improved, I don't think it matters because all that does is create false security against finny attacks. The fix that that came out of this was removing all the text on the bitcoin wiki that you added which suggested that accepting zero-confirmations were safe so long as you listened for conflicts... text I don't think most people knew was there until the paper pointed it out.

I got the impression that the research was about in store only zero-confirmation transactions, and Finney attack is impractical in those settings.

[gmaxwell]

I got the impression that the research was about in store only zero-confirmation transactions, and Finney attack is impractical in those settings.

…
No, you misunderstand the Finney attack.

The finney attack is:
(1) I mine a block with a containing a spend of one of my coins to myself, but I don't instantly announce it.
(2) Instantly after that I hand you a unconfirmed transaction spending the same coin.
(3) You do all the network sniffing and probing and checking with miners you like, seeing no double-spends you give up the goods.
(4) I announce the block. You lose. (probably) And if lose you don't know I tried, so I'll just get you next time.

In other words, I make the zero conf you accepted invalid by being absolutely sure that the conflicting txn will win— on account of already having it mined at my expense/risk.

The value I lose depends on how long I delay the block. Modest delays don't cost much— and this cost, in terms of bitcoin at least, will soon be halving.

Sniffing, checking, double spend propagation, and whatever can't avoid this... and it can be scaled by attacking many vulnerable things in parallel.

Of course, zero-confirmation transactions are unsafe absent a finney attack too; as the attacker can announce conflicts to miners and roll the dice on which version will get confirmed. Various somewhat complicated things can be done to reduce the risk in the non-Finney case by noticing a double spend (and one way of making propagated double spend alerts not be a huge DOS vulnerability was posted to bitcoin-dev about a year ago), but because they don't do anything for the Finney case, I'm skeptical that they're really worth implementing: Even with them the advice really needs to be that you should not accept zero confirmation transactions when you don't have any bitcoin external recourse or assurance, or you're at least rate limited in a way that you can't be robbed blind.  For digital goods transactions this is a bit unfortunate... but in a some other cases you have some other recourse and even if it's limited it's probably enough to mitigate.

[Mike Hearn]

"Real" well, it's real if you don't follow the advice widely propagated and embedded into the reference client: Don't accept zero confirmation transactions

That is unrealistic so you may as well give up on the idea right now. People do and will accept zero confirmation transactions because they want to do a trade immediately, so it may as well be made to work better.

I disagree with calling improved double-spend notices _a fix_, as finney attacks _can't_ be fixed.

Finney attacks are only an issue for transactions where the attacker can very precisely control the time at which they make the trade (ie, entirely automated trading websites). They aren't likely to ever be an issue for things like supermarkets, vending machines, other in person transactions where you don't control the exact time at which you pay. However confusion attacks like those described in the paper are an issue.

And while double-spend notification could be greatly improved, I don't think it matters because all that does is create false security against finney attacks. The fix that that came out of this was removing all the text on the bitcoin wiki that you added which suggested that accepting zero-confirmations were safe so long as you listened for conflicts... text I don't think most people knew was there until the paper pointed it out.

Yes and I think that set of edits was naive. People will accept zero confirmation transactions: period, end of story. We can either make that work better and help people understand the risks, or just watch them go ahead and do it anyway without understanding the risks. Pretending that if the wiki doesn't discuss the topic people will always wait for a block doesn't get us anywhere.

[Sergio_Demian_Lerner]

Check the thread https://bitcointalk.org/index.php?topic=106026.0 where I proposed an alternative alert system to the double-spend alert system proposed in "Two Bitcoins at the Price of One".

It's much better in terms of bandwidth usage, reliability and backward compatibility.

[muyuu]

Zero-confirmation transactions are always going to be problematic. If you accept them in a situation where an attack can be prepared with a lot of time in advance then you had it coming. In any other situation and with most people simply not taking them this attack is never going to happen. Just the low chance of happening to mine a block exactly when you have the chance to try this is enough to make this a non-problem IMO.

If instant transfers are so demanded, there will be centralised services like vouchers from exchanges or account-to-account transfers.

[jgarzik]

Zero-confirmation transactions are always going to be problematic. If you accept them in a situation where an attack can be prepared with a lot of time in advance then you had it coming. In any other situation and with most people simply not taking them this attack is never going to happen. Just the low chance of happening to mine a block exactly when you have the chance to try this is enough to make this a non-problem IMO.

If instant transfers are so demanded, there will be centralised services like vouchers from exchanges or account-to-account transfers.

Or green addresses.

[Pieter Wuille]

If instant transfers are so demanded, there will be centralised services like vouchers from exchanges or account-to-account transfers.

There is nothing wrong with accepting zero-confirm transaction IF the receiver is aware of the risk; and many probably underestimate those...

My preferred solution is still a third party that insures against double-spends or otherwise invalid payments.

[gmaxwell]

Yes and I think that set of edits was naive. People will accept zero confirmation transactions: period, end of story. We can either make that work better and help people understand the risks, or just watch them go ahead and do it anyway without understanding the risks. Pretending that if the wiki doesn't discuss the topic people will always wait for a block doesn't get us anywhere.

Please link the edits you think are naive. I didn't intentionally remove any discussion of the risk. IIRC, I only removed the statements that it was safe to accept zero confirm transactions so long as you listen for conflicts— advice that was particularly horrific since conflicts aren't forwarded (something which was well known long before the paper), but isn't fixed by conflicts being forwarded.

Of course, situations where you have recourse externally to Bitcoin— often the case for offline buyer present transactions— are another matter; but thats independent of the propagation of conflicts.

[Mike Hearn]

That's the key point of disagreement. It is safe for many (most?) sellers to accept zero confirmation transactions if you can see conflicts, which is hard to do reliably today because it requires tons of connections, but would get a lot easier once they are forwarded.

The situation in which you risk losing your money requires you to be selling a service or good that can be delivered very quickly, and selling it to anyone at a time of their choosing, and the buyer must be willing to wait quite a while for it unless they represent a huge amount of hashing power. Many merchants don't fall into that category.

Almost all merchants that fall into this category today are selling something like intellectual property, maybe computing resources or perhaps some kind of currency exchange. For intellectual property the cost of the good is very likely to not make waiting around to mine a block worthwhile. You wouldn't be able to chew through enough computing resources in the window of time before reversing the payments for it to be important. Currency exchanges face a lot of risk so it makes sense for them to require blocks.

Incidentally I think it'd be good to make an effort to explicitly shun services like GPUMAX. Mining is voting and it's clear that many miners don't realize that today. Putting reminders into the documentation for mining tools, the forum sections, etc would be cheap and beneficial.

[markm]

Incidentally I think it'd be good to make an effort to explicitly shun services like GPUMAX. Mining is voting and it's clear that many miners don't realize that today. Putting reminders into the documentation for mining tools, the forum sections, etc would be cheap and beneficial.

If mining is voting, gpumax is probably bread and circuses, or at least bread. So while its a nice idea it seems likely "good luck with that" might apply.

-MarkM-

[Serith]

I got the impression that the research was about in store only zero-confirmation transactions, and Finney attack is impractical in those settings.

...

The value I lose depends on how long I delay the block. Modest delays don't cost much— and this cost, in terms of bitcoin at least, will soon be halving.

To reduce the cost of Finney attack it has to timed be with a purchase, and in case of in-store purchase the possible delay makes Finney attack impractical. For example, an attacker would have to camp near the store for many hours and as soon as a block found rush into the store to make the purchase and hope that meanwhile some one else won't find a block.