Bitcoin Forum

Is there a solution to the following method of stealing something from retail (groceries, coffee, a TV, etc)?

The owner of BTCGuild walks into a store and selects something.  He goes to the cashier who accepts bitcoin.  He hits send, the cashier sees the transaction (the "spend transaction") and says "thank you", and the miner walks away.

Now, there have been no confirmations on that transaction yet.  As this is retail, the cashier can't have the customer waiting around for a block or 3 to get written.

The miner kept a log of the spend transaction and knows exactly which bitcoin he spent at the store.  When he logs into the pool operating software, he attempts to write a different transaction (the "steal transaction") to send this bitcoin instead to a different address (a double spend).  Since this is the owner of BTCGuild, he's able to write the next block 30% of the time and successfully steal from the store.

The best part about this is that in the 70% of the times when some other miner writes a block, and the spend transaction is written to the blockchain before the steal transaction can be written, no one knows that a theft was attempted.  The steal transaction never gets propagated on the network until it gets written to the blockchain.

Someone knowledgeable please tell me there is a solution to this.  How could retail trust bitcoin if miners could sometimes steal from them?

From when he starts the transaction to when it shows up instantly in the POS machine, is this information relayed by miners or by anyone who has the bitcoin client open?

Yes.  The spend transaction is relayed through the nodes, but it is not yet included in the blockchain.

Isn't this a classic double-spend scenario and not isolated to miners?

This is one of the current bitcoin flaws for retail purchases, correct?  Confirmations are essential and they take time.

It's a slight variant.  A non-miner could be caught by the store because his double spend would be broadcast on the network.  The miner doesn't need to broadcast his double spend.

But eventually it will hit the blockchain, right?

I'm sorry, I'm probably missing something here.

 
First off, let me give you the name we call this attack. We call this attack the "Finney Attack". Feel free to Google it for more discussion of it.

Well, let's start out with the simple answer: they just have to. However, that's not as big of a deal as you think, since most retail already accept a form of payment that can be reversed by a determined attacker 100% of the time: credit cards. Therefore, 0-confirmation transactions are, in many ways, actually safer than one of the most common ways people already transact.

As far as preventing it, once we are in a world with no block subsidy, merchants can chain the fees for currently unconfirmed transactions in such a way that the longer it takes the attacker to find a block, the more fees they would be forced to give up because the fees were dependent on the transaction that was double-spent.

If only there were third parties that were willing to handle these transactions for us...  Perhaps they could collect a fee for assuming the risk inherent in retail.

How about this?  The customer walks in, picks stuff out, goes to checkout.  They swipe a small magnetic card through a sensor to authenticate.  The POS terminal then checks online to see if a third party is willing to take on the risk based on that customer and the purchase amount.  The purchase amount is then either deducted to the customer's pre-paid balance with that third party, or added to a debt owed to that third party by the customer.

Any of this sounding familiar?

edit: added the word "retail" in the first paragraph.  Damn tablet browser.

Credit card reversals aren't such a big problem.  They affect your trust and you can only reverse so much until you lose your card and the ability to reverse.  A reversable transaction that is not tied to trust is completely different issue.

I would argue that in-store purchases are very much tied to trust. At least if you value your identity.

The problem is much greater in the case of online spends where there is no camera pointing at your face.

For that matter, mining pools could offer double spending protection on a subscription basis.

All a merchant needs is to positive confirmation from a large enough fraction of the hashing power that a conflicting transaction will not be included in a block. The size of the fraction needed is just enough that it would be uneconomical for an attacker to attempt a double spend for the size of a given transaction.

one way this problem could be solved is by asking to see the persons id and then calling the cops

Satoshi already predicted that Merchants would setup their own mining clusters, purely for this reason.

My expectation is also that by the time we will be able to widely pay with bitcoins in stores, that the cluster of miners will be so big, that it will be hard for anyone to get a big share. (10%+)

Lastly, don't underestimate a merchant that is getting robbed, they will find something to reduce the risk to minimal proportions.

And yet in-store carding happens. So long as the goods aren't too valuable the cops don't do much about it, AFAIK.


Only for digital goods. Physical goods have to be shipped, which takes time and provides the opportunity to wait for confirmations.

And that's why I said "determined attacker". A determined attacker would use stolen credit cards.

However, you're correct about casual attackers. Fortunately, since casual attackers wouldn't have a mining farm, they'd succeed so rarely that it's barely worth mentioning.

I am fairly sure the chance of a steal transaction becoming valid is not 30% even if the thieve controls 30% of the hashpower/nodes, the real probability has to depend on the time passed(how many blocks are found) between the two transactions.

Well I assume retail will simply tell customer to "wait for confirmations" before handing over good. This delay can be mitigated by faster confirmations i.e. paying a reasonable transaction fee of 0.01 BTC per kb. CreditCard payments also take some seconds to confirm.

For now, retailers simply have to tell Bitcoin customers to "wait for confirmations" before shipping/handing over goods.

A retailer accepting bitcoin would probably have to have its own copy of the blockchain, so it can verify transactions on its own local trusted node without having to wait for the network to confirm it.