SERIOUS VULNERABILITY related to accepting zero-confirmation transactions

[Peter Todd]

If you do not accept zero-confirmation transactions this vulnerability does not affect you.

However if you do be advised that a previously unknown coin-stealing attack has been found that allows zero-confirmation transactions to be double-spent with a trivial amount of effort and without having to have access to any mining capacity.

Details will be release as soon as a patch is ready. In the meantime do not accept any transaction without at least one confirmation unless you fully trust the sender not to defraud you.

Mods: please copy this to important announcements.

[1713532830]

1713532830

[1713532830]

1713532830

[BasementMiner!]

Accepting zero-confirmation coins is nothing but trouble. Those who accept these transactions without considering the consequences deserve to lose coins.

As such, Satoshi Dice requires zero confirmations to play because it uses the inputs of the bet it receives as win payout to mitigate the risk of the house having a disadvantage.

[🏰 TradeFortress 🏰]

If you do not accept zero-confirmation transactions this vulnerability does not affect you.

However if you do be advised that a previously unknown coin-stealing attack has been found that allows zero-confirmation transactions to be double-spent with a trivial amount of effort and without having to have access to any mining capacity.

Details will be release as soon as a patch is ready. In the meantime do not accept any transaction without at least one confirmation unless you fully trust the sender not to defraud you.

Mods: please copy this to important announcements.

Umm, this is not new. It is incredibly easy to double spend 0conf coins.

1. Send TX with lots of inputs and no fee
2. Send same coins with a fee

2 will win. Double spent. SatoshiDICE was vulnerable to this, so is many others

[Stephen Gornick]

Umm, this is not new. It is incredibly easy to double spend 0conf coins.

1. Send TX with lots of inputs and no fee
2. Send same coins with a fee

2 will win. Double spent. SatoshiDICE was vulnerable to this, so is many others

Doing what you describe doesn't always result in a double spend.  The difference is that with SatoshiDICE, if your initial wager does confirm you still get back 98.1% over the long run -- i.e., these are wagers and the house edge is 1.9%, so over time, the cost of failed attempts is only 1.9%.  So if it succeeds once every fifty times, you profit.
 - http://bitcointalk.org/index.php?topic=130764.0

Now instead if you are the thief and paying for coffee, and this double spend attempt succeeds only one out of five times, the coffee shop will thank you for coming back so many times in your attempts to cheat them (as the shop still makes money overall even after losing the revenues from the one sale where the double spend attempt succeeded.)

And the only reason that double spend on SatoshiDICE worked was because the transaction was initially being ignored by the main pools (being that the amount of data was larger than normally allowed without a fee being paid, and then no fee was paid) so eventually a miner who was likely using a modification (not part of the Bitcoin.org client) which accepts a subsequent transaction where a higher fee is paid, even if it is a double-spend.  Don't expect the major pools to adopt this modification.

While a merchant can't cut the risk entirely, there are a few things that will make attempting double spends like these to be uneconomical for the thief.  SatoshiDICE modified their backend to no longer show wino/loss immediately (on 0/unconfirmed) for transactions where no fee was paid until those no-fee-paid transactions see one confirmation.   A merchant could take a similar approach and also impose a delay when no fee is paid.

As far as retep's find, I look forward to knowing what was discovered.  

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

[John (John K.)]

As this is stickied by someone but not posted in the Important Announcement subforum, I'll take the liberty to post it there too.

[gmaxwell]

Seems that the post is creating a ton of questions. So here are some of the answers I'm giving.

(1) Yes, retep's post has substance.
(2) It's really not specific to any particular client software.
(3) Some people will consider this obvious / old news / not-a-bug: but—
(4) many things accepting unconfirmed transactions are vulnerable, and more vulnerable then they believed themselves to be which substantiates that it really is news
(5) Generally accepting unconfirmed transactions is really risky for a multitude of reasons, one of these reasons being in fact the meta-risk that it's harder to reason about the safety of unconfirmed transactions than confirmed ones.
(6) People are being hesitant with details until vulnerable sites are fixed and improved software is made available that helps lower exposure for those foolhardy enough to continue to accept unconfirmed transactions.
(7) In the meantime, stop doing it. If you run software that doesn't have an option to stop accepting them, throw out and replace your software because its dangerous and probably has other flaws. There may be times in the future where network instability requires you to increase your confirmation counts.
(8) For those of you who figure it out on your own, you can feel free to brag to me in private, but please have respect for the hard working people who are running businesses that are vulnerable and don't do anything to cause them trouble.
(9) If you're already not accepting unconfirmed txn then this isn't an issue you need to worry about.

[theymos]

Users of the Bitcoin-Qt GUI are not affected.

[Peter Todd]

Users of the Bitcoin-Qt GUI are not affected.

That's unfortunately not true. Bitcoin-QT is affected.

[LightRider]

Is this finding based on work backed by the Bitcoin Foundation? Do the Foundation board members have early access to this kind of information?

[Peter Todd]

Is this finding based on work backed by the Bitcoin Foundation? Do the Foundation board members have early access to this kind of information?

No. I happen to be a member, but I found the problem entirely by myself and have no special role within the foundation. gavinandresen, gmaxwell and other core devs know, but beyond that I do not know who else has been told about the issue other than a highly vulnerable site whom I informed personally.

[Jouke]

Is this something completely new?

Let me rephrase that. Are you aware of this topic? https://bitcointalk.org/index.php?topic=130764.0

[Peter Todd]

Is this something completely new?

Let me rephrase that. Are you aware of this topic? https://bitcointalk.org/index.php?topic=130764.0

Yes. This technique is different.

[bg002h]

Good job retep. Professionally handled too.

[Mike Hearn]

I agree that this problem isn't really "new" per se and the fix in most cases is quite simple. I disagree that there's a general problem with accepting unconfirmed transactions. Once the software people use is upgraded to handle this topic correctly, the issue will go away.

There should be an update for the Android Bitcoin Wallet app soon.

[Kris]

Keeping an eye out for this one. retep or gmaxwell, can you send the details in private, or by mail. Thanks.

[gmaxwell]

I agree that this problem isn't really "new" per se and the fix in most cases is quite simple. I disagree that there's a general problem with accepting unconfirmed transactions.

How many exploitable issues must arise before you change that position?

[Steve]

I agree that this problem isn't really "new" per se and the fix in most cases is quite simple. I disagree that there's a general problem with accepting unconfirmed transactions.

How many exploitable issues must arise before you change that position?

This debate is pointless in the absence of context regarding the transaction in question.  Is there risk in accepting a zero confirmation transaction? absolutely...is that risk acceptable? it depends.

[FreeMoney]

I've been waiting for the right time to end Seals 0 confirm policy, seems like this is the time. It was really nice while it lasted, a playing with fire success story.

[Stephen Gornick]

I've been waiting for the right time to end Seals 0 confirm policy, seems like this is the time. It was really nice while it lasted, a playing with fire success story.

Because an online poker player can purposely lose to another player, that essentially is a form of an Account-To-Account (A2A) transfer, so that makes sense that a a confirmation or two is a requirement before the funds can be used for play.

[FreeMoney]

I've been waiting for the right time to end Seals 0 confirm policy, seems like this is the time. It was really nice while it lasted, a playing with fire success story.

Because an online poker player can purposely lose to another player, that essentially is a form of an Account-To-Account (A2A) transfer, so that makes sense that a a confirmation or two is a requirement before the funds can be used for play.

Right, there just isn't a safe way because you can't reliably tell if losing the money is on purpose or not. So even if you had careful tracking of who loses to whom you wouldn't know if the winnings were safe to pay out.

I plan to make small deposits instant for long time players eventually but some details still need to be worked out. Essentially it will just be a courtesy to loyal players who want to not miss a tournament or something.