Instant confirmation, call it "confirmed-by-owner"

[callem]

In the end we if we can come up with a set of rules to accept 0 conf payments with very little risk, that would be very good news for bitcoin payments in person.

Sure, copy the persons photo ID. Limit sales to values that you'd be comfortable losing to shoplifting. Done.

+1

There are inherent risks in all in-person transactions ranging from counterfeit banknotes to unwarranted chargebacks, stolen cards, etc.

No one is realistically going to orchestrate a double-spend or MitM attack to get a free coffee at starbucks, or even a free TV at walmart. Even in the extremely unlikely event they somehow succeed, the criminal (fraudster) has likely been caught on security camera and it's no different than any other fraud/shoplifting event.

we can do better then that...

simple rules, tx must have a fee, and look for double spend for 30 seconds, and you appear to have pretty damn good protection, even if a double spend is initiated.

asking for ID, and taking on the risk in full, is a crappy solution.

we have near perfect information as to all TX on the network at all times, let us use it!

Yes, that's a 99%+ workable solution in almost all cases - "perfect is the enemy of better" (or however that saying goes).

[Peter Todd]

No one is realistically going to orchestrate a double-spend or MitM attack to get a free coffee at starbucks, or even a free TV at walmart. Even in the extremely unlikely event they somehow succeed, the criminal (fraudster) has likely been caught on security camera and it's no different than any other fraud/shoplifting event.

Don't assume that double-spending is hard: https://blockchain.info/create-double-spend

Even "check the tx has been broadcast" schemes don't work all that well because it's easy to craft transactions that some % of the hashing power will ignore, (like satoshidice bets or the negative nVersion bug) and double-spend those transactions with transactions that they aren't ignoring. Even double-spend alerts don't help here, because the attacker can just wait until they've left the shop/downloaded the file/whatever to broadcast the double-spend.

Things like security cameras and careful monitoring of losses is the way to go.

[CIYAM]

Okay - but f you don't pay then do I need to do anything to stop the repayment (am just trying to clearly see how it gets completed without any race condition)?

I can't decode your question. Can you try asking another way or perhaps give an example?

Maybe I've missed something but if you are holding a valid refund tx. then how is that *disabled* to ensure the funds can no longer be restored (or is that the escrow part)?

[gmaxwell]

Maybe I've missed something but if you are holding a valid refund tx. then how is that *disabled* to ensure the funds can no longer be restored (or is that the escrow part)?

By spending the funds out from under it before the refund transaction becomes valid. The refund is nlocktimed so that it will not be valid until the sufficiently far future.  If you get too close to the refund time then there is a possible race and any payment out of the escrow shouldn't be trusted without confirmations.

The refund exists just to prevent the other party from attempting extortion or in case they get hit by a bus... but its locked and not valid until the future. Normally you wouldn't use it... you'd pay them from the escrow, which is safe because it needs their signature too. If you pay them less than the full value of the escrow either the rest is returned to you or paid into a new escrow (which you also get a refund transaction for before announcing).

[CIYAM]

By spending the funds out from under it before the refund transaction becomes valid.

Okay - thanks - got it now.

[P_Shep]

I still don't see how someone standing at a till can broadcast a double spend.

Some risk analysis would need to be done.

Some assumptions:

Value of transaction likely small
Shop has own centralized bitcoin server which is very well connected.
Shops own infrastructure used to create and broadcast transaction (customer doesn't send via his phone etc.)

For larger transactions $100-$500 (super markets, clothes shops etc) To mitigate the risk, maybe the customer can pay first then is refunded or charged more after the items are scanned. A big cart of groceries could easily take 10 mins. Or if you're standing in line.

[gmaxwell]

I still don't see how someone standing at a till can broadcast a double spend.

Then you aren't thinking with an adversarial mindset.

The person standing at a till is running a special "deluxe doublespender" wallet, that automatically attempts to double spend every transaction they make according to appropriate preconfigured parameters (like delays, connections to known miners, fees, etc).

And sure, there are plenty of things you can do to cope with or mitigate the risk.  None of them, however, begin with being anything less than completely frank about what the risks are.

[BombaUcigasa]

If a TX (with a miners fee), is broadcast, and no double spends accourcs 60 seconds after this TX has been broadcast, we can assume this TX will be confirmed, EVEN if a double spend is initiated after the 60 seconds. because when a miner is validating TXs he will see the first tx ( the one that occurred 60 seconds before the double spend attack) as the valid one.

If a TX (with a higher miner's fee) is broadcast, most current miners will prioritize it and queue it up sooner than the smaller fee one, even if it comes much much later.

If a miner is in collusion with the attacker, by sharing the transaction privately with him, he can simply excuse himself as: I have included one transaction that was valid and correctly prioritized while this person you are referring to as the attacker tried to double spend so there is no way to prove I was involved.

There is a chance of 100% - (100% * miner_hash_power / network_hash_power) that this transaction can be cancelled after being "confirmed-by-owner". For example if the miner is BTC Guild, then 1 in 3 transactions can be reversed under your recommendations.

By changing the bitcoin protocol, there is however an option to incentivize and guarantee that it is better for the miners to act fair than to act covertly. If you are interested in knowing the method (PM me), the "confirmation" period for such a transaction will have an average of 38 seconds and an incentive to force miners to respect transaction age as a meaningful parameter. You can "confirm-by-owner" or "confirm-by-miner-paid-by-owner" before a block is created that includes the transaction.

[gmaxwell]

If a TX (with a higher miner's fee) is broadcast, most current miners will prioritize it and queue it up sooner than the smaller fee one, even if it comes much much later.

Thats not true. I don't believe any miners today will accept a later _conflicting_ transaction even if it has a higher fee, except by accident (e.g. restarting their nodes at just the right time).

Some people argue that eventually some miners will do this because its obviously the greedy-rational optimal behavior, and further that because some miners will do it that it should be the default for all in order to reduce avoid incorrect expectations and to facilitate the fee burning solution to double spending.  This argument hasn't yet convinced everyone.

[callem]

I still don't see how someone standing at a till can broadcast a double spend.

Then you aren't thinking with an adversarial mindset.
...
And sure, there are plenty of things you can do to cope with or mitigate the risk.  None of them, however, begin with being anything less than completely frank about what the risks are.

Agree completely. Being frank about the risks would include assigning probabilities to them and adjusting them over time based on empirical realities, just like card processors and insurance companies do.

One of the main reasons internet commerce took 5-7 years to gain any traction in the 1990's was mass media continually going on about how dangerous using credit cards on the internet was supposed to be. There was a mass misperception that card numbers could easily be stolen 'in transit' while being sent on the internet.

One problem: According to VISA at the time it never actually happened, not even once. Sure, card numbers could be taken from poorly secured merchant servers, retail merchant skimming, etc. but not once was a card number ever shown to be compomised 'in flight'. Anyway, this largely baseless paranoia did provide an excellent start-up environment for Paypal (so you wouldn't have to share your card number with anyone else) and forced the card companies to limit unauthorized-use liability to $50 or so to allow customers to feel safe using them online.

The risks associated with zero-confirmation retail transactions with bitcoin are probably lower (or at least similar) to those associated with credit cards, but the lower fees would probably outweigh any additional risks anyway:

Example:
Someone walks into your cafe in the US, orders a coffee, pays $3 using blockchain. Risk of DS <1%, fee = 0
Someone walks into your cafe in the US, orders a coffee, pays $3 using VISA. Risk of stolen card/chargeback <1%, 3-5% fee

A guy wearing a lulzsec hoodie walks into your TV-store in Bulgaria with a friend, both fidgeting with their phones. They're in a hurry and want to buy a TV with bitcoin. You say no, we only take cash today (in Bulgarian, of course.) Risk of DS = 0  

 
 

[BombaUcigasa]

If a TX (with a higher miner's fee) is broadcast, most current miners will prioritize it and queue it up sooner than the smaller fee one, even if it comes much much later.

Thats not true. I don't believe any miners today will accept a later _conflicting_ transaction even if it has a higher fee, except by accident (e.g. restarting their nodes at just the right time).

Some people argue that eventually some miners will do this because its obviously the greedy-rational optimal behavior, and further that because some miners will do it that it should be the default for all in order to reduce avoid incorrect expectations and to facilitate the fee burning solution to double spending.  This argument hasn't yet convinced everyone.

How can you prove they preferred one or the other transaction? You can't!

Anyone can broadcast two transactions and then falsely blame the miners for helping him double-spend, but in the end, we just see one failed double-spend attempt, nothing much.

[gmaxwell]

How can you prove they preferred one or the other transaction? You can't!

I've helped users many times with self-doublespends when they have stuck transactions that aren't confirming in a timely manner due to low fees. If miners were accepting higher fee replacements these issues wouldn't exist. So I'm quite confident that at the moment they aren't.

I've also never seen a complete patch to produce this behavior and as far as I can tell very very few miners today write their own software.

[BombaUcigasa]

How can you prove they preferred one or the other transaction? You can't!

I've helped users many times with self-doublespends when they have stuck transactions that aren't confirming in a timely manner due to low fees. If miners were accepting higher fee replacements these issues wouldn't exist. So I'm quite confident that at the moment they aren't.

I've also never seen a complete patch to produce this behavior and as far as I can tell very very few miners today write their own software.

That sounds good. Then does this thing work or not: https://blockchain.info/create-double-spend

[DiamondCardz]

In the end we if we can come up with a set of rules to accept 0 conf payments with very little risk, that would be very good news for bitcoin payments in person.

Sure, copy the persons photo ID. Limit sales to values that you'd be comfortable losing to shoplifting. Done.

we can do better then that...

Yes, there is something called off-the-blockchain transactions. You don't need confirmations to send and receive Bitcoin off of the blockchain, so you don't have any risk as long as the off-the-blockchain service doesn't run with your coins.

[P_Shep]

I still don't see how someone standing at a till can broadcast a double spend.

Then you aren't thinking with an adversarial mindset.
...
And sure, there are plenty of things you can do to cope with or mitigate the risk.  None of them, however, begin with being anything less than completely frank about what the risks are.

Agree completely. Being frank about the risks would include assigning probabilities to them and adjusting them over time based on empirical realities, just like card processors and insurance companies do.

...

I think I mentioned risk analysis.

[Sarchar]

Would this strategy work?  Naturally, it isn't without its own flaws either.

Say you're going to starbucks for a coffee.  On your way, you "prepare" your payment (as in the same escrow strategy that gmaxwell suggested), but in a different manner:

Starbucks publishes via a standard URL (say, https://starbucks.com/pubkey) the EC point -- the public key -- to a secp256k1 private key.  The key could change all the time, daily, whatever, that's up to starbucks. Then, you generate another private key, computes the EC point, adds the EC point to starbucks's, then hash that public key to obtain a bitcoin address. You prepare your payment by sending some coins to that address and broadcast the transaction.  Neither you nor starbucks can spend the coins right now.

You may realize that this is split-key address generation, like how vanitygen bounties work.

So you arrive at starbucks, and place your order.  To make a payment, you give starbucks the private key you generated, starbucks can instantly verify that the private key was the correct one and leads to the address you sent coins to earlier and that the coins are confirmed. It's impossible for you to spend those coins because you don't have the other half of the private key.  Along with your private key, you give starbucks a "change" address, they build a transaction sending the prepared coins (minus coffee price) to your change address and they broadcast that transaction, or just give it to you to broadcast.  They don't have to wait for confirmation, they *know* you can't spend the prepared coins.

Suppose you never made it to starbucks and want your money back - you hop onto https://starbucks.com/refund, give them your private key and change address, and they send you back your coins.

I think the cons in this situation are better than the escrow/timelocked version, since you can get your coins back immediately (as long as the vendor is cooperating). The vendor has to be trusted to send you proper change, but I think that's less of a big problem since the vendor has more to lose by cheating you.

You could consider this strategy like purchasing a gift card but getting your change in currency.  You also have the option to return the giftcard completely and don't have to lock away coins using nLockTime.

Thoughts?

[gmaxwell]

Suppose you never made it to starbucks and want your money back - you hop onto https://starbucks.com/refund, give them your private key and change address, and they send you back your coins.

Sorry, starbucks was run by Bernie Madoff and won't return your money. Basically under your scheme: Once you've given them the secret key for the refund they can say "HA HA, mine now!", and even without you giving them the key they can freely extort you ("Give us the key, or we're not talking. Maybe if you give it to us we'll give you back 10%") with no finical loss.

I think the cons in this situation are better than the escrow/timelocked version, since you can get your coins back immediately (as long as the vendor is cooperating).

The escrow/timelock version can give you your coins back immediately if the vendor is cooperating too. The timelocked refund is just there to prevent extortion like "No, sorry, I won't refund your coins unless you give me at least half." or to deal with the vendor getting hit by a bus.

Certainly there are cases where you reasonably can trust the vendor, but in most of those you can probably go all the way to a premature payment and dispense with the split key stuff.

[Sarchar]

Suppose you never made it to starbucks and want your money back - you hop onto https://starbucks.com/refund, give them your private key and change address, and they send you back your coins.

Sorry, starbucks was run by Bernie Madoff and won't return your money. Basically under your scheme: Once you've given them the secret key for the refund they can say "HA HA, mine now!", and even without you giving them the key they can freely extort you ("Give us the key, or we're not talking. Maybe if you give it to us we'll give you back 10%") with no finical loss.

How is this different than handing the starbucks cashier a 100$ bill and oops, he only saw a 10$ bill?

Yes, this scenario involves a layer of trust -- I don't deny that -- but we aren't talking about 100,000$ purchases.  If starbucks defrauded one customer, no other customer would play.  They have a lot to lose by cheating the customer.

I think the cons in this situation are better than the escrow/timelocked version, since you can get your coins back immediately (as long as the vendor is cooperating).

The escrow/timelock version can give you your coins back immediately if the vendor is cooperating too. The timelocked refund is just there to prevent extortion like "No, sorry, I won't refund your coins unless you give me at least half." or to deal with the vendor getting hit by a bus.

Certainly there are cases where you reasonably can trust the vendor, but in most of those you can probably go all the way to a premature payment and dispense with the split key stuff.

True, I had also considered a strategy for building your order before arriving, sending payment (sure, split key or multisig could work here too) and delivering the private key for instant payment.

[gmaxwell]

How is this different

Please read the last line of my above post.

[jedunnigan]

Here is one solution to the 0 conf problem, not sure how viable/practical/feasible it is. It's probably been proposed before, and [may] require an Oracle.

When checking out, two transactions are created by the payer instead of one. The first tx (0-conf) is broadcast immediately by the payer, for amount x. The second tx is broadcast (as a fidelity bond) and given to the Oracle. This second tx spends x amount, but it spends different coins in the payer's wallet.

If the Oracle sees that the coins are double spent or somehow didn't make it to the merchant, the fidelity bond is triggered and the coins from the second tx are broadcast to the merchant. If the original tx is confirmed, the funds from the second tx are returned to the payer.

Obviously this method kinda sucks, because it requires you to have twice the amount of Bitcoins you want to spend. In POS scenarios where you may not be spending huge amounts (e.g. buying a stick of gum) this could be useful. please debunk

edit:nm, peter todd has a more robust version of this: http://sourceforge.net/mailarchive/message.php?msg_id=29185108