Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: Peter Todd on January 11, 2013, 11:14:37 PM



Title: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 11, 2013, 11:14:37 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: BasementMiner! on January 11, 2013, 11:41:11 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: TradeFortress on January 11, 2013, 11:51:28 PM
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


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Stephen Gornick on January 12, 2013, 12:44:18 AM
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


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: John (John K.) on January 12, 2013, 03:17:44 AM
As this is stickied by someone but not posted in the Important Announcement subforum, I'll take the liberty to post it there too.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: gmaxwell on January 12, 2013, 03:39:36 AM
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.



Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: theymos on January 12, 2013, 03:56:28 AM
Users of the Bitcoin-Qt GUI are not affected.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 12, 2013, 07:33:35 AM
Users of the Bitcoin-Qt GUI are not affected.

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


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: LightRider on January 12, 2013, 07:56:38 AM
Is this finding based on work backed by the Bitcoin Foundation? Do the Foundation board members have early access to this kind of information?


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 12, 2013, 09:15:12 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Jouke on January 12, 2013, 09:24:19 AM
Is this something completely new?

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


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 12, 2013, 09:51:21 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: bg002h on January 12, 2013, 01:53:57 PM
Good job retep. Professionally handled too.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 12, 2013, 03:14:11 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Kris on January 12, 2013, 08:10:54 PM
Keeping an eye out for this one. retep or gmaxwell, can you send the details in private, or by mail. Thanks.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: gmaxwell on January 12, 2013, 09:45:23 PM
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?


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Steve on January 12, 2013, 11:26:47 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: FreeMoney on January 13, 2013, 04:00:55 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Stephen Gornick on January 13, 2013, 06:42:47 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: FreeMoney on January 13, 2013, 06:55:54 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: ciphermonk on January 13, 2013, 06:56:41 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: lucif on January 13, 2013, 07:39:15 AM
Hello Bitpay!


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: davout on January 13, 2013, 10:18:37 AM
I fail to see how it's news that accepting 0-confirmation is dangerous.
Anyway, I'm interested in the specifics.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 13, 2013, 03:06:10 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Steve on January 13, 2013, 04:27:45 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: cypherdoc on January 13, 2013, 04:59:38 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 13, 2013, 07:58:50 PM
Quote
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.



Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: MatthewLM on January 13, 2013, 10:43:57 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: davout on January 13, 2013, 10:49:01 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: MatthewLM on January 13, 2013, 11:12:17 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: paraipan on January 13, 2013, 11:36:00 PM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 14, 2013, 12:34:25 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: gmaxwell on January 14, 2013, 02:20:45 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: FreeMoney on January 14, 2013, 03:55:58 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: caveden on January 14, 2013, 07:41:59 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 14, 2013, 08:28:55 AM
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.

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


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 14, 2013, 08:53:23 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: giszmo on January 14, 2013, 09:37:17 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: picobit on January 14, 2013, 10:08:51 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: davout on January 14, 2013, 11:06:10 AM
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.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: piuk on January 14, 2013, 12:14:46 PM
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)

The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 14, 2013, 01:08:39 PM
From a site that swaps unconfirmed coins for confirmed coins. That is not at all the majority of merchants.

The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.

sigh... I didn't want to mention what exactly who I exploited precisely because the network is public.

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

You sure you understand the attack? You don't need to mine at all to pull it off. Email me if you want further clarification.

Only confirmation is persuasive evidence of eventual confirmation.

This is circular.

No it's not. Because clients validate all transactions in blocks against the same rules whether the tx is in the most recent block, or how ever many blocks back, the rules for confirmation are the rules for subsequent confirmation. The rules for every single node on the network are exactly the same; if they aren't you get a network split.

On the other hand there is no single set of rules that decides if a transaction will get into a block in the first place; that's up to miners and the relay-rules of the network itself and every miner and every node can, and does, have somewhat different rules they operate by. Some miners ignore satoshidice tx's, other miners ignore zero fee tx's; it's all over the place.

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.

I'm not one of the core dev's, so maybe they think otherwise, but I'm pretty sure they'd agree that building API's to allow zero-conf transactions to be accepted "safely" sounds like a world of hurt. It's a moving target for one thing as attacks are discovered, and in addition the best ways of detecting them can't be done unless you have access to many different nodes to do network propagation measurement.

If you want to allow zero-conf tx's to be accepted safely, start a service to do so. Have staff that maintain this service, do constant risk analysis and continual threat detection, and if you have good reason to believe your counter-measures are adequate, offer insurance on transactions using the service. It's not a new idea, but there isn't anyway doing it right now as far as I know, so maybe you can make it work?

Putting this functionality in the satoshi client just leads people to believe the functionality works properly. It'll just lead to more examples of people getting defrauded, and we don't need that.

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

The API's already let you use Bitcoin safely: just don't accept unconfirmed transactions.

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.

It'd be nice of you to ask the core-devs and other members of the community about when is right to release the full details. In addition, when that time comes, I think it'd also be nice to let me do it.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: MatthewLM on January 14, 2013, 04:35:56 PM
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.

Well, for sure BitPay might be useful for transfers to a bank account but I'm talking about merchants that want payment in bitcoin. Why use a middle-man when you can directly use bitcoin? Bit-Pay offers bitcoin transfers for 0.99%.

BitPay has misrepresentation in their promotional material: "With Bitpay you can eliminate the risk of Fraud" This is false.

You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Kris on January 14, 2013, 07:15:25 PM
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.

You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin.

Not really no.

I feel obligated to inform that many places use zero-confirmation in one way or another. BitPay and WalletBit is no exception.

But imagine this from a customers point of view, they do not want to stand in the store waiting 1 minute or more for a confirmation, so therefore we have to let the mobile checkout (point of sale) use 0 confirmation to display payment done notification to the customer as soon as we register the payment, even if this poses a risk for the merchant.

At the same time from the merchants point of view they will still have to wait 6 confirmations for the payment to arrive in their account and be transferred as bitcoin payment to their own wallet or as bank transfer to their local bank account. We do have issuance if a finney attack or other takes place by a "customer" out in a store using Mobile Checkout (See it here (https://walletbit.com/pay/mobilecheckout/159c1b70ce1dee8a6d84be16336c904a)), but then again this is very unlikely to happen unless they got remote access to a setup at "home" able to do the attack.

As far as eCommerce or online shops, there really is no risk in accepting bitcoin via WalletBit or BitPay, since both system sends out a Instant Payment Notification when a defined bitcoin confirmation number have been reached.

Here it is up to the merchant if he wants quick notification of payment or very safe with no risk at all = 6 confirmations. It is as simple as setting your Notification in your account to High, Medium or Low in your WalletBit business tools, I think the same goes for BitPay in one's account.

In the end if we could iron out every attack involving zero-confirmation that would of cause be the way to go, but I can say right away that this won't happen, there will always be a loophole to find if you search enough.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: paybitcoin on January 15, 2013, 04:38:22 AM
Yes, I'd think it is similar to the process of paying with a check at the grocery store. The store takes the signed piece of paper that promises that the bank will deliver them the money. You can still drive home really fast and withdraw all of your money from your account, rendering your earlier check useless to the store.

The same way banks deal with this kind of fraud (with verifying proof of identity when presenting the check, check-scanning machines that can talk to the bank to verify the check, and of course real legal liability for bounced checks) will definitely come to Bitcoin as well at some point. I can definitely see the case where merchants may only accept co-signed transactions from big payment providers, so they can have someone to sue when the funds don't come in.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: zvs on January 15, 2013, 10:58:25 AM
can anyone tell me where all these 0 fee blocks spamming my logs are coming from?

i already got rid of the 2 IPs it's showing as relaying on blockchain

i guess i need to add IPs to transactions in source too =/

2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0b511b75aa9aa442434a59765b98b4fd2756524fd8f9c2b11f5c888bde9958f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0d0a79791b5b78a022331a6389297e3eee9b9f3034c878d8c6cee2412691571
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efb77fc35a8a6bc33e5c58b284e81be2b353874cb13838ff4c74ca51b5ba793c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efbdc9e1a1bf3a3c7fd3132cb777431ffa73d6fc836e1d1b70489cdccdfeac6c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0543537bb137ae02c5eefb93dc5d362623ba8480e1563b4937aca5013da5854
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f1c34730e5a0940c65e4a0b37cc2d1fce9ce0f1c730d3de0b5e005d0f0b4db7f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f74b022b82f9a3e1d0f0515b05e85564bfa07ad0c9e6ace89b2ce7f2752011b6
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees cf540360acbdcdf6afa58ee2adec991301d4ba992e2be242071087b45f05be93
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees d3c90dbdde9eec6063571cd0236d6bfd142a373d65e25f4fa3e975ace446e524
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d8543699b679c45cd36705f025c54d3039a1ed2dfb63466c193b320dec5e400f
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d9286580caabcfecaa67904cd217207e92885ed71c37ec4377336bda0c23e207
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees ee399a5e806540e0fd1bc1d46f37a34ce74a6811550dc5f5683c2bf5028443b2
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f0115ef694c04dcbc48068755498a6d5158d316380459f096bae8f7724227176
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f026656b07abc5708d06e763583f56e3cc9124dde85e2ddad1ee724d5645c1db
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f39996eb7d6a45f9193daf58ca5f20d378c81eb0598746fd5e1cd692658709fb
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f6b3421a3b01240ed9d7744350ebf00bfd0b966e991b98d02da7b83d5596ea69
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cddf3a1683d1429b6e85da4f96039041fb42bd12e36766720db95eafd0235b7a
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce7c0dbfa5d2a89787a62d9d1473fe60662622fa6d14d93dcfdb460e7f92b15d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cfe8b131f8d24bcb97a32367724991667ddc077c2ae0f84b6f4b3c37a04e37b4
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d744f1bb7049f720f7913b2bc43e763aeabb069bce156262463f436e7daca37d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbfd6af1f0a106d3abbf110f445031e1988fe810088bcf110d2a865983d5b928
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ccebe83aa809a3f5446398f0e5449803f71b55e635143e83edcf451e25e84b20
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cd6d323d755e65efa638bc6157c89bc88b6cacc8b5181d438e36ec28bb7426a3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce1f54c78b8f3e0ebe04fafbd5c6d5c46aab92e4e4d13ef1a6832a223154fe18
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce32ad556d883d3df90ac3463f94e854fe9d3e016bfcf603d1c0e00fddac2043
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf233c426e941967014cd118cbf70c38186e3da5f17629b37863e97d676d8f8d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf5c391b229c6d0d59580bd894ccfcd42811ee4a5a456a6648c9bcdd7b34e9ac
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf91339258163883e1747cf48c54590542f7acbe7f8a2aba527752398c360baa
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0d2edd026073b8e548623be491ffd5acf57d4db454a9c041a4cb56a726308de
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0ea334244eca1dc51ed875959a126434ec70368dd62059961a8fb704449dfe3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d1ef53d215ce4620790af274e8374410121837db59d099b311829dd51fb21070
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2878c33afaa8023e2695bff2c83586068cc447ddaf684705ce10bb07cf193b7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2d21775d847bf1f8b0819c30f4acdaa24e4b1067012de6f2109f93e1d0daac7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d302d1a7354fdddd120c5582a14d86b5a04ca678ddb730eae665a6bc90872a32
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d56cdda9a4d2006814affe057bc4edb2d7adec39bb62faf54b8f557e93ea7870
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d5d02daa5e19f5f7c4d037d60949bc6cbd0cc52e49f80cbd1409f7973269f07e
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d71fa20523418f39c6908545401c6a85c95bf254cb00c955887bcdeabfaeaa56
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d83b16d1400497a17ed1d1a9fe1c2cce4a5f9bf55dae1832d3755b39ee7f2a77
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees db009790fe3f7416dc97b43212aaa847b151c81c24c972610aa3d36951ab47a1
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbd43f0addf1a654ac8965a49f99f7e013dd78294a3fc66848738e8b0b90f1d9
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc3f7b3515416ec6fec66b6c47fac7d822a03abadc0794c6de58afe21f561b2b
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc5b696042870930d58b4351f7e088bd51a2ae3863d86946d2e7bf3f17e8571a

and so on


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Jan on January 15, 2013, 11:41:09 AM
They are not related to the vulnerability discussed in this thread.
Your bitcoin node is complaining about transactions that do not meet the minimum relay fee. So basically what it tells you is that it will not forward the transactions to other nodes in the network. These transactions may however still reach a miner and get included in a block as some nodes have other relay policies and/or are connected directly to a miner who includes any transaction regardless of fees. This is for instance the case with the first one on your list: ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: zvs on January 15, 2013, 03:42:29 PM
They are not related to the vulnerability discussed in this thread.
Your bitcoin node is complaining about transactions that do not meet the minimum relay fee. So basically what it tells you is that it will not forward the transactions to other nodes in the network. These transactions may however still reach a miner and get included in a block as some nodes have other relay policies and/or are connected directly to a miner who includes any transaction regardless of fees. This is for instance the case with the first one on your list: ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9

I think they are related, in that someone was trying to exploit (or test) it.  I mean, why else would you throw around 20 .000082 transactions at once?

I know how the relay works.  I'd like to designate these transactions as 'misbehaving', but not with a huge 24hr ban, more like 1hr.  I'll probably change it in my client later.

http://blockchain.info/ip-address/78.47.187.253

They start at 2013-01-15 10:40:03 and end at 10:58, about 400 in total, on that IP.  There was one other German node that was getting some first and also a UK node.

http://blockchain.info/address/1Ct8vwFzpWGzUyNagYUyV6NFP5cjBNkgoW       or      http://blockchain.info/address/18dzWGn9wMHA46GmBFRNgwrT3yJneKaKkA


entirely unrelated


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: libertaad on January 16, 2013, 02:48:07 AM
We had temporarily disabled zero-confirmation deposits at bitZino, but we have now re-enabled them thanks to Mike Hearn's help. We've also added a series of additional anti-fraud checks in order to ensure our risk from a double-spend attack is minimal. As always, we only allow withdrawals back out of our site after a deposit has received multiple confirmations.

I'd really like to thank retep and Mike for their responsible disclosure and help in getting this issues resolved. We've tipped each of you 5 BTC as a way to say thanks from bitZino for helping us operate our business in a secure manner.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 16, 2013, 04:32:29 AM
I'd really like to thank retep and Mike for their responsible disclosure and help in getting this issues resolved. We've tipped each of you 5 BTC as a way to say thanks from bitZino for helping us operate our business in a secure manner.

Thanks! Glad to help.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: phelix on January 19, 2013, 07:59:48 PM
still no details? you got me curious...



Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: meebs on January 20, 2013, 04:48:26 AM
well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: ErebusBat on January 20, 2013, 02:58:16 PM
still no details? you got me curious...
Take a look at bitcoin magazines website.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Luke-Jr on January 20, 2013, 03:06:16 PM
still no details? you got me curious...
Take a look at bitcoin magazines website.
The article does not cover the vulnerability this thread is about.

I'm sure disclosure will come in time.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 20, 2013, 07:23:38 PM
For what it's worth, I'm working on changes to bitcoinj so that apps built on that library are protected from this and related issues. It's not done yet but making progress. I'm not sure if anything is being done to the main C++ client.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Gavin Andresen on January 26, 2013, 07:56:56 PM
The reference implementation patch is scheduled for the (real soon now!) 0.8 release:
  https://github.com/bitcoin/bitcoin/pull/2223


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: nelisky on January 26, 2013, 08:07:24 PM
And diceoncrack fell on to this attack, it seems... https://bitcointalk.org/index.php?topic=138988.0

I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update. I think that there are only two things I can do at this point; don't accept 0 confirmation wagers without fee and make sure the coins used on the wager tx are already on a block. Had I these measures in place the attack would have failed.

That or simply not take 0 confirmation wagers, of course.

If anyone need details about this attack let me know, I can dig the transactions that got rolled back.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Luke-Jr on January 26, 2013, 09:10:36 PM
I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update.
This will be fixed in 0.8 (though require you to use a new option the first time you start it).


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 26, 2013, 10:18:18 PM
And diceoncrack fell on to this attack, it seems... https://bitcointalk.org/index.php?topic=138988.0

I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update. I think that there are only two things I can do at this point; don't accept 0 confirmation wagers without fee and make sure the coins used on the wager tx are already on a block. Had I these measures in place the attack would have failed.

Luke is correct above, and you can also simply apply the patch Gavin posted to your 0.7 bitcoind src. I've tested this before - I wrote a slightly different version of the patch a few weeks ago - and it worked fine.

If anyone need details about this attack let me know, I can dig the transactions that got rolled back.

I'd be very interested to know; there are many variations of this attack.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: nelisky on January 26, 2013, 11:26:42 PM
This particular attack we endured doesn't seem to be related to lockntime, as far as I can tell. The coins are originally sent back and forth across a few addresses a few times in small values and finally they get aggregated in one address like A (http://blockchain.info/tx-index/46601326/e586b0cfa885c5fc8960205a9bfec228dc0dfa496c04b20172c66d1f9760076d) and B (http://blockchain.info/tx-index/46646986/2076b8e5be0fcaed6e6652ea2a89a45d755462764f852e3e3b9fcda3bb035e3e).

One vout from each of A and B (18 and 1 is one particular example) are then aggregated into C, which is then bet on Martingale at DoC with tx D. The long chain of tx without any fees takes a long time to get confirmed by the network and somewhere along the line C is replaced by another Tx, completing the double spend.

The now rolled back transactions C and D were:

Code:
{
"hex" : "0100000001f677169e7a5739be1e4c462e88fb1cc394a4ea061e4a1defc1f4d0e4e4aca9cf000000008b483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdcffffffff016a48c323000000001976a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac00000000",
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "cfa9ace4e4d0f4c1ef1d4a1e06eaa494c31cfb882e464c1ebe39577a9e1677f6",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d01 04e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc",
"hex" : "483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 2ddfe9616ddf358d81546a3a18034fc88b349656 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"15BZeHbK4gX8YugqBsHwyTnUAqF5GJjgBW"
]
}
}
]
}

Code:

{
"hex" : "0100000001c0e62a6ec5b1088d9341154de1855568e38c31b63702fb1d951f6e04b3ec1c2b000000008b4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415fffffffff016a48c323000000001976a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac00000000",
"txid" : "acaebd04202864eef6af5b9df8ca70b88875bc4cf540a6d0f8b010a87f00145c",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"vout" : 0,
"scriptSig" : {
"asm" : "30450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e501 04696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f",
"hex" : "4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 7d3b0ada4990415ac12b968174371c8e67dc691b OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1CRACKLiwFrZbAQz1yb9w22onHCMLbiMTY"
]
}
}
]
}


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on January 27, 2013, 12:15:30 AM
Yup, that's another known attack. bitcoinj is going to support recursive analysis of transaction depth IIRC, so you'd be able to say "don't accept chains more than x long"


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on January 28, 2013, 10:18:07 AM
Do you know the miner who mined the double spends?

Although playing games with the consensus protocol will always be possible, the difficulty of executing such attacks can be made much harder through some simple community policing work to ensure that legitimate miners don't accidentally get co-opted into creating double spends.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: jgarzik on February 04, 2013, 04:18:31 PM
well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?

In general...  agreed, with this sentiment and the opinions others have expressed in this thread.

However, it should be noted that certain situations may benefit from a mixed approach.  If you are a merchant shipping a physical product, the purchase process might look like
  • Request payment
  • User sends bitcoins
  • "Payment received!"
  • Hours or days pass, while product is packed and prepped for shipment
  • Order validation: Check and make sure bitcoins have not been double-spent
  • Ship product

So it is really product/situation dependent.  A situation like bitcoin exchange or SatoshiDICE would seem like the ideal example of when to not accept zero-conf transactions; alternately BitcoinStore.com would seem like an excellent example of what could follow the multi-step order flow above.

Multi-step Zero-conf-now-check-later gives the best user experience: fast immediately confirmation of funds receipt, with the security of multiple confirmations before final product delivery/enablement.



Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: pointbiz on February 10, 2013, 03:55:17 PM
Can someone now disclose the issue as promised? .... retep?

It appears to me that Mike Hearn has had the correct non-panicky level headed approach to this. Can someone explain how this is an exploit as opposed to expected functional behavior? It took me a lot of reading to determine this is a non issue?!? Am I wrong?

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

 It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on February 11, 2013, 05:37:29 AM
Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

True transaction replacement probably needs to be done as a separate P2P layer, and in any case always has the problem that there is nothing stopping miners from mining older versions of the transaction that they know about.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

That's the main reason this was considered a serious issue: code was doing exactly that and not taking into account that transactions can be made invalid until thousands of years in the future. (Maximum nLockTime setting locks the transaction until July 18, 11515) There are lots of UI's that make no distinction between transactions that can be mined now and ones that can't. The same applied to services; I did after all steal 5BTC from blockchain.info exploiting this oversight.

It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?

A non-final transaction can not be included in a block until it finalizes and thus miners have nothing to do with the issue.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: caveden on February 11, 2013, 08:19:27 AM
Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

That's what I feared. You're seriously killing nLockTime for good?

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

Anyways. This is a powerful feature. The fact that's not yet exploited doesn't mean otherwise: multisig itself is not really exploited so far, and I don't think you'd say that feature is "not important enough".


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Luke-Jr on February 11, 2013, 09:04:34 AM
nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on February 11, 2013, 09:27:47 AM
nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.

Specifically nLockTime is only considered non-standard when the transaction is not final yet. That is the locktime hasn't been reached, and the transaction is not eligible to be included in a block. Non-standard just means that nodes won't relay such transactions on the P2P network, but nothing stops you from saving the transaction yourself and broadcasting it when the locktime is reached and the transaction finalizes.

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

You can do that just fine even if non-final transactions are not-standard. Just create the transactions that send the money back to the client, set the nLockTime so that they will not be valid for 3 months, and then sign them. You can freely give the client copies of these transactions. As the three months approaches, move the coins to invalidate the txin's of the previous set of locked transactions and create new refund transactions. If the refund transactions are ever needed, just wait until they have finalized, and broadcast them on the P2P network as you would any other transaction.

Ultimately the thing is transaction replacement just doesn't work the way people want it to because you can always replace a transaction by finding a miner willing to ignore the non-final tx in their mempool and willing to mine another one for you. Additionally mempool contents don't last forever; I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: phelix on February 11, 2013, 10:06:11 AM
Am I correct in assuming that while this is a serious issue for some sites it does not currently affect most clients and can be fixed for those affected with relative ease?

Once again this makes me wonder if Bitcoin guts really have to be so twisted and complicated. All this just sounds like an invitation to overlook serious issues.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: caveden on February 11, 2013, 11:09:38 AM
I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Peter Todd on February 11, 2013, 11:33:54 AM
I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

That's exactly what people were doing, or really, what the software people were using was doing. Keep in mind that a non-time-locked transaction that depends on a time-locked transaction is effectively time-locked... fixing the issue that way isn't trivial and would have required a lot more careful testing to be absolutely sure it worked; I should know, I wrote a patch that did exactly that kind of analysis before writing a version of the nearly trivial fix that Gavin wrote. It took me a few days to be convinced, but I think he made the right choice. There are also other mostly theoretical vulnerabilities related to non-final transactions that have not been disclosed as far as I know. They are fixed by Gavin's patch and are not fixed by just handling non-final txs differently in the UI. They also can-not be used to steal funds.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: Mike Hearn on February 11, 2013, 01:29:04 PM
We can bring time locked and replaceable transactions back when somebody does the work necessary to properly unit test the code, think through the potential issues/angles of attack and patches them, makes sure the DoS/abuse potential is minimized etc.

For now, Luke-Jr has it right - the feature was unused as it's meant to be deployed along side replacement. So we'll have to bring them back together.


Title: Re: SERIOUS VULNERABILITY related to accepting zero-confirmation transactions
Post by: pointbiz on February 11, 2013, 03:23:20 PM
retep, thank you for the clarifications. Could you TL;DR in the OP? And mention it is patched in 0.8?