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

Please stop claiming that unconfirmed transactions are safe*†‡™.  

It is not the case, has never been the case, and never will be the case. The policy miners use to determine what transactions they accept into block is not knowable to clients.  Because of that when you have an unconfirmed transaction all you can do is speculate if it will be mined in minutes, hours, or never. Because of this it is very hard to reason about how long one might be before its accepted and what the odds are that a conflicting transaction could make it in first.

Unconfirmed transactions _may_ be an acceptable risk in certain contexts— a transaction which is safe because the sender would never rip you off, or because you have a copy of their street address, or which is safe because you can revoke service— those are safe on their own merits, and safe with or without a 'few lines'. Accepting an unconfirmed transaction is nearly equivalent to accepting signed email promising to pay. It's evidence of an intention, but it's not very binding. The people who can safely handle unconfirmeds after your fix are the same who could handle them without: those who don't depend on security from Bitcoin.

The unfortunate status quo is that a lot of parties are accepting unconfirmed transactions who shouldn't be— who are highly exposed, who have no other security mechanism— they're getting away with it because no one is even bothering to try to attack.

Without disclosing retep's issue, I'll point to one that is already public:    I create a long series of unconfirmed transactions, weighing in at 72 megabytes.  I pay you with a transaction who takes this long chain as one of its inputs.   The soonest this transaction can be confirmed is twelve hours from now, but it's likely it would take much longer.  In that time I can happily provide a conflict on one of the inputs to one of several pools that ignore zero/low fee transactions, and twelve hours is more than enough for them to solve a block.  You will not be paid but the transaction looked okay to you, you likely will not ever hear about the conflict until it is in the chain, as the nodes surrounding the miner in question will not relay it.

Does your few lines of code fix this?  There an infinite number of ways which transactions may be differentially attractive to different nodes, and so there are an infinite number of reasons miners may take a later transaction rather than an earlier one. Only confirmation is persuasive evidence of eventual confirmation.

How easy a security problem is to fix has little to do with how dangerous it is until you fix it.

You know, I actually performed this attack, and quite successfully steal a few Bitcoins worth of a service from a site. I don't know what safeguards the site happened to have, but it's not implausible that I could have made off with thousands. (the site has been fixed)


If they know about the issue.

Bitcoin isn't just big well-run sites you know. It's a huge eco-system with a lot of small players, many we probably don't even know about, and many of those unknowns probably don't follow the forums all that closely. It's also average people running Bitcoin clients, and those clients are vulnerable too. Lots of people use Bitcoin but don't understand the intricacies of how it really works, such as why zero-confirmations is easily orders of magnitude less secure than one-confirmation.

I'll guarantee you that some scammer will try to separate some new user from their Bitcoins using this exploit in a over-the-counter trade on irc or face-to-face: "guess it's just taking awhile to confirm, nah, don't be worried, happens all the time, look I gotta go pick up the kids, can you send me the paypal tx?" Previously we thought the scammer in that scenario at least had have access to a bunch of machines and some luck, but it turns out that's not true. From the point of view of that average guy making a otc trade, yes there has been a fundamental shift: a shift from attacks that are annoying and difficult to pull off consistently to one that works reliably every time.

Those major sites are more than capable of asking a member of the dev team. As for why this was published on the forums, easy: not accepting zero-conf tx's has a fairly low cost; it's perfectly reasonable to tell people, yet again, to stop doing it unless they can afford to be defrauded. Not to mention, it's much safer to make the announcement now, in public, than to hope that while we go off telling big sites in secret no-one else figure it out, or the secret leaks.

+1 btw, it was in the protocol right from the start so I knew it wasn't safe, and general consensus was always 6 confirms.

No they do not remove the risk of fraud, Steve just clarified that they do not. And bitcoin does not have chargebacks. BitPay hasn't removed that, bitcoin has. The problem is with 0-conf transactions.

Convenience. It might not make sense to you, but it could make lots of sense for people who just want to sell stuff over the internet.
Also you're taking the wrong perspective here, BitPay removes the risk of fraud, chargeback fraud, that's the promise.

I thought part of your service was to remove the risk of fraud on behalf of the merchant. Merchants might want to use your service to receive payments through a bank account but I see no point for merchants to waste 0.99% on BitPay for bitcoin transfers. What on earth is the point in that? A pointless middle-man, and a waste of money.

Unless you're talking about a totally different issue to the one reported to the bitcoin-security list, this is simply not true.

For sites that are vulnerable to this simple bug, the fix is a few lines of code and they can continue as before.

There seem to be a lot of major sites who are saying they haven't been notified in private about what's going on here. That is an issue. Making alarmist claims stating there has been some fundamental shift isn't helping that.

I will say it again. The issue you reported is not a fundamental issue with unconfirmed transactions or even a protocol exploit. Any business that accepts them today without issue can tweak their software and continue as they were before.

Anyone who wants details, just post in this thread and I'll send them to you. Then after a week or so of that it'll be time to just post the full story here.

this is very helpful to know.

I just want to clarify some misconceptions about how BitPay processes transactions.  We do not accept 0 confirmation transactions, we never have.  We also only accept transactions that are immediately eligible for inclusion in a block.  While our user experience is that an invoice is shown as paid right when someone sends payment, we only guarantee and credit a merchant's account after 6 confirmations (we have considered dropping that to 3 confirmations, but at the moment it is 6).  Merchants do have the option of getting notified about a paid invoice immediately, after 1 confirmation, or only after BitPay guarantees payment.  Depending on the nature of their business, a merchant may accept the risk of a double spend and deliver their product or service with zero confirmations.  At some point in the future we will offer to cover that risk for transactions below a certain value and we'll begin to mitigate the risk via relationships with large miners and mining pools.

Basically we used to think double-spending a zero-confirmation transaction took some effort, and doing so could be detected by the receiver. It turns out that's not true.

Now my advise for a business is pretty simple: ensure that your business logic for how you accept Bitcoins is designed in such a way that you can determine the total amount of zero-confirmation transactions you are accepting at any one time, and limit that amount to a level where you would be OK is every one of them was reversed. Watch them carefully and be willing to stop accepting them at all if problems develop.


This problem is something that affects a wide range of Bitcoin-accepting software; it is not specific to the satoshi implementation. Patching and deploying a fix isn't something that can be done by the Bitcoin developers themselves. Not accepting zero-conf transactions however is something everyone can do.

I fail to see how it's news that accepting 0-confirmation is dangerous.
Anyway, I'm interested in the specifics.

Hello Bitpay!

Hackers are much quicker to adapt than business owners.

For this reason, I feel that it is smarter to inform the community about critical security vulnerabilities once they have been patched and deployed. Historically, that's how most bitcoin issues have been handled.

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.

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.

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.

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.

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

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

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.