Instant Transaction - how?

[WiW]

Okay, so I searched but couldn't find.

Suppose I want to buy a meal at a fast foot place. I don't want to wait ten minutes for a confirmation (because it's fast food!), but the fast food court would probably want at least one confirmation (it's not a big loss, but in the past I've coordinated with my brother at another fast food court to order with the same private key simultaneously).

I can only think of two ways to make instant transactions:

• Physical BTC, but that means both parties have to trust the issuer of said physical BTC
• Central banking, where both parties have accounts in central banks which speak with one another

Is there any other way which doesn't involve 3rd parties?

[1714046030]

1714046030

[1714046030]

1714046030

[1714046030]

1714046030

[1714046030]

1714046030

[1714046030]

1714046030

[DeathAndTaxes]

The probability of a double spend under that scenario is essentially nil.   Bitcoin doesn't need to be 0% fraud it just has to have a transaction cost (equipment, fees, fraud losses, etc) that is lower than the alternatives.

Nobody is going to attempt to double spend fast food purchases.

1) It is low value, hard to control/time, and in person.

2) Even if you and another party did try to engage in a simultaneous spend fast food isn't "instant food" it takes what 1-2 minutes from the time you pay until you receive the food.  Anything longer than 15 seconds and the probability of a non-finney double spend is essentially zero. Most likely the merchant will leave the implementation details to a payment processor.  The payment process would use the time between payment and delivery to look for double spend attempts.

3) If you want free food it would be easier to just use a stolen credit card.  When is the last time you were asked for ID or even had you sign a receipt when getting fast food?

[Akka]

Maybe there is a way with using multisig transactions, where 2 (or more) Private keys are required to send the transaction.

You have one and the Fast Food place the other, so you could only double spend with an agreement from the fast food place.

This solution would you require to have kind of a burger king address though, in which you already have BTC.

See: https://en.bitcoin.it/wiki/Address#Multi-signature_addresses

[WiW]

Even if you and another party did try to engage in a simultaneous spend fast food isn't "instant food" it takes what 1-2 minutes from the time you pay until you receive the food.  Anything longer than 15 seconds and the probability of a non-finney double spend is essentially zero. Most likely the merchant will leave the implementation details to a payment processor.  The payment process would use the time between payment and delivery to look for double spend attempts.

Excuse my noobishness, but are you suggesting that 1-2 minutes after the "transfer", the merchant poll the network and see if there is another transaction from the same address? That way, if the merchant finds another spending hopping around the network, even if there are no confirmations yet, he will know I'm trying to fraud?

Basically, instead of waiting for a confirmation, look at the transactions hopping around the network and be confident that the odds of fraud are low enough if the original transaction is the only one so far on the network even if it's not yet reached the new block?

[Akka]

The probability of a double spend under that scenario is essentially nil.   Bitcoin doesn't need to be 0% fraud it just has to have a transaction cost (equipment, fees, fraud losses, etc) that is lower than the alternatives.

Nobody is going to attempt to double spend fast food purchases.

1) It is low value, hard to control/time, and in person.

2) Even if you and another party did try to engage in a simultaneous spend fast food isn't "instant food" it takes what 1-2 minutes from the time you pay until you receive the food.  Anything longer than 15 seconds and the probability of a non-finney double spend is essentially zero. Most likely the merchant will leave the implementation details to a payment processor.  The payment process would use the time between payment and delivery to look for double spend attempts.

3) If you want free food it would be easier to just use a stolen credit card.  When is the last time you were asked for ID or even had you sign a receipt when getting fast food?

Now Imagine the following:

There is an automate of any kind, lets say a coke automate.

I want a cold coke, I press the coke button and immediately a QR-Code is displayed. I scan it, click on send and my coke drops out.

There would no money need to be stored on the automate, hell it wouldn't even need to have the private keys.

But especially for applications like this, there would be a double spend app for your phone in no time.

[WiW]

This solution would you require to have kind of a burger king address though, in which you already have BTC.

This isn't a solution I was looking for, because it requires that the long confirmation happen in advance...

I'm thinking about how to make cash-like (perhaps even in-person), immediate transactions between two strangers without relying on 3rd parties (/edit: considering the network is a 3rd party, but a very slow one/). I guess that's not a very bitcoin friendly paradigm...  

[TangibleCryptography]

Excuse my noobishness, but are you suggesting that 1-2 minutes after the "transfer", the merchant poll the network and see if there is another transaction from the same address? That way, if the merchant finds another spending hopping around the network, even if there are no confirmations yet, he will know I'm trying to fraud?

Basically, instead of waiting for a confirmation, look at the transactions hopping around the network and be confident that the odds of fraud are low enough if the original transaction is the only one so far on the network even if it's not yet reached the new block?

Exactly but the merchant's node (or highly more likely a specialized "real time" payment processor) doesn't need to poll the network.  Other nodes will continually relay new tx to other nodes (including the merchant).  This stream of new tx will include the double spend.  The monitoring is simply a matter of comparing unconfirmed order transactions to the set of all unconfirmed transactions which exist on the network.

A payment processor would be a better option as they can let Burger King be an expert on making Burgers and Burger King can let the payment processor be an expert on detecting realtime threats.  The payment processor likely wouldn't have a single bitcoind node but dozens or maybe hundreds spread out all over the world which could collect and share information.

Note: This type of monitoring can't be used to detect a Finney attack but the limitations of that type of attack don't lend it to the "physical world" scenario you described.  Also this type of monitoring does require someone to have detailed knowledge of how the Bitcoin network works.  A casual noob shouldn't naively assume 0-confirms are safe because they will see the double spend.  Lastly some level of risk analysis is required.  The threat profile against an ATM which accepts BTC and dispenses cash is a lot different than a vending machine or fast food biz.

[WiW]

A payment processor would be a better option as they can let Burger King be an expert on making Burgers and Burger King can let the payment processor be an expert on detecting realtime threats.  The payment processor likely wouldn't have a single bitcoind node but dozens or maybe hundreds spread out all over the world which could collect and share information.

In other words, instead of waiting for the money to arrive in my account after confirmation, you're making sure the buyer isn't sending more transactions to the network by monitoring the network?

That's actually a pretty good solution. Except, if I were to meet a stranger at a bus stop, and we wanted to trade a large amount of BTC but don't have much time... The receiver would have to be signed up to some sort of service in advance, yes? And this service would have to serve individuals and not just Burger Kings?

Thanks for the informative responses!

[nevafuse]

Is there any other way which doesn't involve 3rd parties?

A script could be written to record double spends from the network.  Then you could create a "credit score" based on address usage & double spend history.  But you'd have to be REALLY well connected to catch double spends since they aren't normally propagated very far.  And it would require someone to use the same set of addresses which defeats some of the anonymous nature of bitcoin.

But I don't see any reason that leveraging multiple 3rd parties just like averaging credit scores from Transunion, Equifax, & Experian are a bad solution.  It does require using a 3rd party, but competition will weed out the bad ones.  Then places that require instant payment will have to decide if its worth paying extra to prevent double spends or to accept the risk.

[TangibleCryptography]

In other words, instead of waiting for the money to arrive in my account after confirmation, you're making sure the buyer isn't sending more transactions to the network by monitoring the network?

Correct.

That's actually a pretty good solution. Except, if I were to meet a stranger at a bus stop, and we wanted to trade a large amount of BTC but don't have much time... The receiver would have to be signed up to some sort of service in advance, yes? And this service would have to serve individuals and not just Burger Kings?

Well no.  Remember the part about risk analysis.  Meeting an anonymous stranger to swap massive amounts of currency is a completely different risk profile than fast food.  The reward is higher for the attacker and the consequence to the victim is also higher.  What works in one scenario isn't going to work in another scenario.

Large irreversible transactions should wait for confirmations.*  Real time monitoring is more applicable to physical world retail type transactions.  These are transactions which already (despite the ease in obtaining and using stolen credit cards) have a low rate of fraud.


* There are alternatives but they require a trusted third party.  Escrow could be used.  Both parties using the same off blockchain processor (i.e. MtGox codes for example) eliminates the  need for the blockchain.  Having the funds in an address which requires a trusted third party to be a multi-sig is another option (if you trust the trusted third party won't double spend then you don't have to trust the direct party as both key holders would need to conspire).

[Gabi]

If you can make a bitcoin transaction then you have a client and it's connected to internet. Thus it is connected to other bitcoin nodes, thus it have access to all unconfirmed transactions. If someone try a double spend while buying a burger, it's automatically detected, it's trivial.