Topic: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions - page 4. (Read 11439 times)

Good job retep. Professionally handled too.

Yes. This technique is different.

Is this something completely new?

Let me rephrase that. Are you aware of this topic? https://bitcointalksearch.org/topic/success-double-spend-against-a-satoshidice-loss-130764

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.

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

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

Users of the Bitcoin-Qt GUI are not affected.

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.

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

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.
 - https://bitcointalksearch.org/topic/success-double-spend-against-a-satoshidice-loss-130764

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

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

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.

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.