Topic: Risk of accepting 0-confirmation transactions with Bitcoin-QT? (Read 4179 times)

Anyone have any statistic on how many of bitpay customers are actually immediate point of sale and how many are shipping or delivering much later.  It would be a bit untrue to lump merchants who clearly aren't doing immediate exchange into that double spend claim.

A more accurate takeaway would be that a successful double-spend in an retail POS environment would be an extremely unlikely event, probably on the same order of probability as having the power go out in the middle of a credit card transaction, or being struck by lightning on the way to the bank with your daily deposit.

Despite the numerous theoretical possibilities some of us have discussed for years now, the advent and success of bitcoin payment processors have provided some basis for a 'reality check' on the true risks, real or imagined, of accepting bitcoin in a coffee shop, etc. As it turns out, most payment providers are comfortable charging a maximum transaction processing fee of about 1% (Coinbase, BitPay, etc) while accepting liability for double spends, etc. From that, it could be inferred that the real-world transaction losses incl. 'race' double spends, Finney attacks, vector76 attacks, etc. must all amount to somewhat less than 1% of transaction volume. In other words, almost certainly less than "losses" with regular retail credit cards transactions, which are guaranteed to be at least 3-5% in fees alone.

In fact, BitPay has previously stated publicly that they have never seen a double-spend in any of their transactions. As of Sept. 2013 they have transacted over USD $30M (in bitcoin). In other words, as a retailer, I wouldn't lose much sleep over it, at least until the facts suggest otherwise. You're far more likely to have someone pass you a fake $20 bill than you are to lose $2 on a double spend for a coffee.

deepceleron, thanks for the link. Green addresses sound like a good solution.


It will be easier in the future to not have to convert between bitcoin and other currencies, and just do all transactions in bitcoin. Also with all the fees that credit card companies charge, there is a huge value in being able to use bitcoin for point of sale payments. Maybe all prices would be 1% cheaper in such a world.

Any reason you are trying to fit bitcoin into this Starbucks world?  Is there some particular need a ton of other payment systems aren't filling already for your coffee purchases?  For all the problems bitcoin does elegantly solve I think lack of trust in 0-conf transactions seems to be a small price to pay.  Speed will always be traded off for accuracy and security.  I could be wrong but if you must have it wouldn't a better solution be to have a quasi paper wallet situation where a merchant gets a private key from you that controls a small set amount of BTC and broadcasts the transaction himself to all the nodes and if needed sends you change.  Not sure if in the future major miners will have established relationships with major merchants and will be able to prioritize their transactions.

Not mentioned here is green addresses.

https://en.bitcoin.it/wiki/Green_address

If a zero-confirmation payment needs to be trusted immediately, it can be sent on behalf of the purchaser from a service that controls the green address and guarantees funds are not going to be double-spent if they come from that address.

Unfortunately MtGox doesn't pay Bitcoin transaction fees, so it is likely (and has been witnessed multiple times) that their green address payment won't confirm for hours or more, the opposite of the desired effect.

You can have a trivial protocol for multisignature assignment with an anti-replay oracle.

An anti-replay oracle is just some dumb trusted program which signs anything anyone gives it, with a constraint that it only signs once (or a finite number of times) for a given key.

You write a transaction sending your coin to a multisig You+Anti-replay-oracle, you ask the oracle to write you a refund nlocked to some expiration time in the future.

The oracle signs, and then you announce the payment into the escrow.

After that confirms you can pay people from the escrow instantly and they can trust that you will not double spend them before the published expiration time so long as they trust the anti-replay oracle to behave faithfully.

There are many ways to address these cases... just requires some UI innovation to make good software to make it practically usable for people.

The point is that 0-confirmation transactions can not be trusted.  As such, if you want to accept 0-confirmation transactions, you have 2 choices.  Get your trust from somewhere else (such as identification, or trusted third party), or accept a certain amount of loss due to fraud.

It's the "get your trust from somewhere else" that is likely to see some innovation, although innovation in pre-pay systems eliminate the need to be concerned about 0-confirmation at all.

We know how the bitcoin protocol works now, which I think is a pretty good clue to what sorts of solutions will and won't work in the future. We also have a sense of what sort of future protocol changes would be acceptable to the community.

Your credit/debit card examples are straightforward analogies to the current system. I agree those would work, but the downside is that you couldn't be pseudonymous. Merchant pre-pay means that you can't just pop into the store for a coffee or to grab some pretzels and be out in a minute, which I think is a deal breaker for any long term solution. The mining contracts idea also can't support super fast transactions, because the proof of work still needs to be solved regardless of what agreement the store owner has with miners.

The more I think about it, the more I think companies selling pseudonyms which can always be cashed out will work really well. I just have to figure out the technical details.

Too many people try to fit the bitcoin concept into their current understanding of the credit/debit card user experience or their current understanding of the cash experience.

Bitcoins are something new.  As such, they will necessitate a paradigm shift.  If bitcoin makes it into mainstream use, it's quite likely that the purchasing experience will be quite different than anything you're currently accustomed to.  Entrepreneurs will see to it that the best ideas succeed and businesses will adapt. We really don't have any god way of predicting what that experience will be like.

Some possibilities off the top of my head:

Bitcoin credit card - You swipe this card at a merchant and the "credit card" company makes the payment to the merchant.  The "credit card" company is a well known, established, trusted, probably regulated business, so the merchant has no concerns about not being paid.  Then once a month the "credit card" company sends you a bill.  In order to receive this "credit card" you have first gone through a vetting process whereby the company has enough information about you on file to prosecute you in the courts if you fail to pay.

Bitcoin debit card - You swipe this card at a merchant and the "debit card" company makes the payment to the merchant.  The "debit card" company is a well known, established, trusted, probably regulated business, so the merchant has no concerns about not being paid.  The "debit card" company only sends an approval code to the merchant for amounts less than what you currently have available in your pre-paid account with them.

Merchant pre-pay - As you enter the business (or before you leave home to travel to the business) you make a "deposit" to an address supplied to you by the merchant.  The merchant provides you some method of proving that a particular deposit was made by you.  The deposit earns confirmations while you are shopping.  When you are ready to leave, you provide your proof of deposit to the cashier.  The cashier then totals up your purchases and sends you back any necessary change.

Mining contracts - Merchants sign contracts with mining companies. The contracts stipulate that transactions received from the merchant will be handled with a higher priority than any transaction received elsewhere regardless of transaction fees.  In exchange for this service, the merchant makes regular payments directly to the mining company. You don't broadcast the transaction at all, but instead use a device that is capable of signing transactions that are provided and returning the signed transaction.  The merchant then hands over the signed transaction to the mining company to be included in its next block.

More likely though, what eventually evolves won't be anything anybody has even thought of yet.

I think you're right that swiping some form of ID wouldn't be that horrible, just not as awesome as remaining pseudonymous during point of sale transactions. I guess IDs could be 'anonymous' identities that simply cost a non-trivial amount to obtain, then these IDs could be flagged by merchants as associated with double-spend attacks. So I buy an anonymous ID for $10 and use that for all my coffee / candy bar purchases, knowing that if I ever double-spend my ID will stop being accepted and I'll need to buy another ID for $10.

I didn't mean to suggest Bitcoin wouldn't work in general. I know infrastructure can be created on top of the existing protocol to make point of sale transactions work, the same way credit cards are built on top of bank transfers which take several days.

It's just as easy to refute small charges on a credit card (the merchants only recourse is to sue... which isn't worth it— unlike Bitcoin which can become effectively irreversible in the hour timeframe credit cards are reversible for months), shoplift, pass bad bills, or invalid checks. And yet business go on. There are many unfortunate costs of doing business they just get priced in.

(and I'm not sure why you don't think that reading off some ID would be unacceptably burdensome— if it was a transactional norm it could be perform in the same way as a credit card payment: a card swipe)

In any case... In these cases any time the attacker does this, he's running the risk that he gets caught and gets a kept by the shopkeeper and gets a free ride to the police station, like any other shoplifter.

You're confusing Bitcoin the currency and Bitcoin the payment network. Or do you go around telling people that USD is impossible to use on the internet because its little bits of paper and paper can't be sent digitally?   There are way to have secure (or more secure) instant transactions, but they don't just involve pretending that an unadorned unconfirmed Bitcoin transaction is safe.

Your doublespend-qt is already part of blockchain.info, BTW: https://blockchain.info/create-double-spend

Thanks gmaxwell for the detailed reply.


So let's say Jimmy writes a new version of BitcoinQT called DoubleSpendQT. Whenever it sends a transaction, it broadcasts the 'honest' version to the entire network, and simultaneously sends {a transaction using the same input to an address its user owns} to all the big well known mining nodes.

Let's say some local businesses start accepting bitcoin. So I download DoubleSpendQT (the phone version), and start using it to buy cups of coffee, candy bars, etc. Even if I'm standing in the business's shop, I don't see how that will help the business avoid getting scammed. The local business isn't going to want to copy everyone's ID for every small purchase.

My takeaway here is that it is so simple to scam people who don't wait for confirmations and don't have time to verify IDs that Bitcoin can't work in the long run as a point of sale payment method in its current form unless businesses are checking IDs. I was hoping that 0-confirmation doublespends were complex enough to cost the attacker ~$50 or more each time so that small transactions could be more frictionless. Even if a coffee isn't that expensive, if people can use DoubleSpendQT at their local coffeeshop and get a free coffee half the time every time they buy coffee, it seems like a lot of people would do so.


My bad, I was writing sloppily. Sorry about that. When I was talking about 'from the same address' I meant 'using the same input transaction'.

This is Bitcoin-101 basic tech support stuff, so I've removed it from the development discussion subforum.

If Jimmy can find you, he can send one transaction to you while sending a conflicting transaction just to major mining pools. You and your immediate peers (via you) will hear one transaction but a majority of the hashpower will hear another.  So jimmy has pretty good odds of ripping you off. Also, presuming the trade you were making with him was a fair one (one where he wouldn't mind losing the doublespend race) he doesn't have to be 100% successful, he would be happy if he only won the race some of the time.

Miners are restarted sometimes, and some miner may be (or may start to) accept later conflicting transactions if they pay a higher fee. Until a transaction is confirmed you really don't know what miners will mine.  Jimmy may have made the first transaction unattractive to the network for reasons your node doesn't understand, it's also paying so blacklisted address or it's violating some new anti-dos-attack heuristics... sometimes later transactions get confirmed instead of earlier ones.  Jimmy could also be partnering with a miner or paying one off more explicitly.

Indeed, its trivial to announce the transaction concurrently to fractions of the network so one half gets one version and another half gets another. This can give jimmy 50/50 odds even when he doesn't know where you are on the network.

No, it wouldn't currently and not only that— it probably _couldn't_ tell you because nodes will not relay a duplicate transaction, so if you tell your peers about the version you like, none of them will likely pass onto you the version you don't. It's somewhat hard to make alerts possible without opening up a trivial DOS attack on the network.

Your comments ("a transaction from the same address") also suggest a profound misunderstanding about how Bitcoin works under the hood.  Addresses are largely irrelevant, they're a fiction created by wallet front ends (and blockexplorer sites).  A transaction spends specific coins which are identified by their output index and the creating txid.  A conflicting spend is one that spends the same txid:vout, a "from" address doesn't come into it— and in fact transactions have no "from" addresses at all.  Jimmy spending unrelated coins is not risk to you.

There are plenty of cases where doublespending isn't a risk— the customer is standing in your shop, you copied over his photo id, the item being sold is a two bitcent candybar... or he's buying some high value electronics over the net but you won't ship until tomorrow (and can check the transaction).... or he's purchasing a VPS service and you can shut him down if the transaction doesn't go through.  But in all cases a zero confirm transaction is itself a risk, if the entire trade isn't a risk its only because things external to the transaction moot the risk.

Let's say my friend Jimmy is trying to do a double-spend against me, because I'm willing to give him money in exchange for 0-confirmation bitcoins. Can he reliably do this? Here's my understanding of how the situation would have to go down:

Jimmy modifies the source code of his own copy of Bitcoin-QT to allow him to do this doublespend attack.

Jimmy sends out a transaction to the network, sending 1 BTC from address 123 (which he controls) to address 456 (which I control).

Question 1: is there any way Jimmy can send this transaction just to my Bitcoin-QT client and not to the network in general? I'm assuming Jimmy is a master programmer and can modify Bitcoin-QT at will, or write his own wallet/node software.

Question 2: even if Jimmy could send the transaction only to me, since I am running the standard Bitcoin-QT client, I would automatically broadcast it to the entire network, and there's no way Jimmy could stop this (unless he controlled my access point to the Internet), right?

So it seems Jimmy has to execute the doublespend very quickly, otherwise the entire network will see the transaction from 123 --> 456, and will reject any later transaction from 123 --> 789 (assume Jimmy controls address 789). So let's say Jimmy broadcasts the transactions 123 --> 456 and 123 --> 789 at roughly the same time. He gets lucky and my computer sees 123 --> 456 first so it looks to me like everything is normal.

Question 3: Is it pretty trivial for Jimmy to broadcast the transactions in a way were roughly half the nodes in the network get one, and half get the other? Or is there something about how the network works that would make this unlikely? Maybe his broadcast messages for both transactions would tend to travel along other nodes in the same sequence, so the one he sent first would be overwhelmingly likely to be seen by almost all nodes first?

Even if my node saw 123 --> 456 first, I think my node would receive the transaction 123 --> 789 because it would be broadcast to me from other nodes in the network.

Question 4: My node would reject the above transaction, but would Bitcoin-QT alert me to the fact that not only was the payment I just got unconfirmed, but that it had just rejected a transaction from the same address? Basically this would be a doublespend alert, and would let me know something fishy is happening, and to not hand over any money to Jimmy until I get at least one confirmation.

If Bitcoin-QT would alert me in the above scenario, then isn't it pretty safe to accept 0-confirmation transactions after waiting only 10 seconds to verify that Bitcoin-QT doesn't flag any other transactions as being seen with the same 'from' address? The only thing I really need to worry about is Jimmy controlling a lot of the network's hash power so that he might solve the next block on his own and explicitly prefer his transaction to himself over his transaction to me, right?

EDIT: Maybe if Jimmy sends the transaction to himself with a higher transaction fee, then most mining nodes would include his transaction to himself in their block rather than his transaction to me, even though the transaction to me was seen by them first. Anyone know if most miners currently would pick the larger fee transaction if they see two incompatible transactions?