SERIOUS VULNERABILITY related to accepting zero-confirmation transactions

[ciphermonk]

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.

[1715216111]

1715216111

[1715216111]

1715216111

[1715216111]

1715216111

[lucif]

Hello Bitpay!

[davout]

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

[Peter Todd]

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.

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.

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.

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.

[Steve]

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.

[cypherdoc]

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.

this is very helpful to know.

[Mike Hearn]

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.

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.

[MatthewLM]

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.

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.

[davout]

What on earth is the point in that?

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.

[MatthewLM]

What on earth is the point in that?

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.

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.

[paraipan]

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

+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.

[Peter Todd]

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.

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)

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.

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.

[gmaxwell]

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.

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.

[FreeMoney]

Mike isn't saying that 0 conf is safe. He's saying that with a small fix it is as safe as (most people thought it was) it was before which may be not safe at all or totally fine depending on what you are doing.

[caveden]

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.

Come on, it's safer than that. To pull off a double-spend, you need some technical expertise, and perhaps the help of a miner. While Mr Everybody can easily break a promise, I wouldn't say he can make a double-spend.

But yeah, you're right that if you have no way to go after your customer or interrupt the service, you probably shouldn't be accepting unconfirmed transactions.

I create a long series of unconfirmed transactions, weighing in at 72 megabytes.  ....

Software can/should be clever enough to detect such a thing.

[Mike Hearn]

You know, I actually performed this attack, and quite successfully steal a few Bitcoins worth of a service from a site.

From a site that swaps unconfirmed coins for confirmed coins. That is not at all the majority of merchants.

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?"

Somebody doing currency exchange for unconfirmed transactions with no delay at all has always been vulnerable( to Finney attacks). And doing it for PayPal with untrusted partners has been known to be risky for years.

I don't understand why you assert that the attacker doesn't need a bunch of machines. They still need to mine.

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.

All bitcoin transactions have risks, including ones that have been included in blocks. There are lots of applications that want ~instant delivery and can provide it with little or no fraud risks, if they have an understanding of those risks. As demonstrated by the number of sites that do it.

Like I said, I'll post the full details in a week or two. As you note yourself, not every site can be contacted manually. Besides anyone who wants to can figure out what you're talking about just by looking at recent changes to various client apps anyway.

[Mike Hearn]

Only confirmation is persuasive evidence of eventual confirmation.

This is circular.

Anyway, I'm not making my point clear. You're saying, in effect, that a Bitcoin payment can take completely random and arbitrary amounts of time to arrive, including never arriving.

This is the kind of statement that is both technically true and not really useful. It's like me saying email does not guarantee delivery times, or even delivery at all, so only fools would send an email about some future event.

If I said that, I'd be technically right, but in practice such a statement would be ignored because everyone knows from experience that 99.9% of the time you can send an email and it'll arrive at its destination a few seconds later.

What we have with the Bitcoin community today is people using APIs that don't make it easy to do accurate risk analysis. Of all transactions, not just unconfirmed. For instance the current best practice is to wait some number of blocks before considering a transaction "done" but the actual hardware cost of mounting an attack doesn't depend on the number of blocks, it depends on how difficult those blocks were to create (yes, I'm oversimplifying a bit). So really sites should think about confidence in terms of gigahashes of work done, but in practice no sites actually do. I've tried to support this kind of approach in bitcoinj, where you can query any wallet transaction to find out how much work has been done on top of it, but I never had time to really push this idea.

So it's up to us, the community, to build APIs that ensure users can use Bitcoin safely.

In your case, as caveden points out, detecting a massive chain of unconfirmed transactions that has low fees is easily done using software. There are no cases where wallets will build such things today, so a quick fix is just to forbid it. More generally, estimating confirmation time based on history of observed behaviour can be done by any full node and over time, when provided with the tools, merchants will use them to optimize their risk and user experiences.

[giszmo]

Mike Hearn I like how you push for your "it depends" point of view. Nothing is only black and white and we will find ways to estimate risks. Accepting a transaction will be based on the blockchain, the transaction in question, confirmations, time since first seen, count of pools reporting to have seen it, the client's record, recent double-spend alerts, the weather, whatever … matched against a threshold set by the merchant.

[picobit]

Come on, it's safer than that. To pull off a double-spend, you need some technical expertise, and perhaps the help of a miner. While Mr Everybody can easily break a promise, I wouldn't say he can make a double-spend.

We all thought that this was correct.  But as I understand retep, he is trying to warn us that this is not correct, that there is a way to reliably double-spend without the help of miners.

That of course increase the risk of accepting zero-confirmation transactions, and for many people may move it from a small but acceptable risk, to a risk too great to run.

But there is of course a reason that all exchanges require at least 3 confirmations: Accepting zero-confirmation transactions will never be 100% safe.

[davout]

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.

You're cute and all but I was talking about CC chargeback. I'm saying the promise of BitPay to merchants is to eliminate CC chargeback risks (by using an alternative payment system obviously).
Of course you can accept BTC without BitPay, but not every internet merchant wants to know about Bitcoin, or understands it enough to feel comfortable accepting them themselves.