<p>First of all and most important: do only business with people you trust. That does not mean that you have to have known them for a long period of time, but only that the person that is doing business with you is more likely to optimize his profit if he does not scam you.</p>

<p>I'm not sure about the odds of successfully launching a double spend attack after a x seconds wait, but what you can do is write some software that connects to some of the major mining pools and waits if your transaction (or a malicious double spend attempt transaction) shows up. It would be great if mining pools had a web API for checking which transactions are likely to get included in their next block, but unfortunately they don't. That means that you would have to program such application yourself (I do not know of any existing libraries with this functionality, but enlighten me if they exist).</p>

<p>Finally, you could always work with <a href="https://en.bitcoin.it/wiki/Green_address" rel="nofollow">green addresses</a>. If your partner agrees in trusting some third party, transactions can be cleared instantaneous.</p>

CC BY-SA 3.0
2014-04-27T15:26:10.073Z
Good suggestion about connecting to mining pools. Only doing business with people I trust, or green addresses, are not an option, I'm afraid. It's supposed to accept payment from random customers (i.e. complete strangers).
RocketNuts
CC BY-SA 3.0
2014-04-28T11:19:59.810Z
Then there is no solution, except to connect to many nodes as possible, and especially to mining pools. Just connect as a dummy node and fetch the block they are working on. AFAIS there is no way the pool can cheat on you, if it is decentralized and open, like P2Pool.
Jori
CC BY-SA 3.0
2014-04-27T15:13:31.553Z
2014-04-27T15:13:31.553Z
Jori
<p>From
<a href="http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13" rel="noreferrer">http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13</a>, here is what services like MyCelium and BitPay may be doing:</p>
<blockquote>
<p>More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.</p>
<p>What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.”  This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.</p>
</blockquote>
<p>But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender.  That's why the blockchain exists in the first place.</p>
<p>One risk of relying on &quot;transaction confidence&quot; is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network.  This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.</p>
<p>In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you <strong>or</strong> any of its 0-confirmation inputs could be double-spent, to your detriment.</p>
<p>Frankly, even 1-confirmation transactions aren't risk-free.  Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.</p>
<p>If you're serious about trying to minimize the risks of accepting BTC in &quot;real-life&quot; (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation).  Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it.  Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.</p>

CC BY-SA 3.0
2014-04-27T16:15:27.080Z
Thanks for the detailed answer. Are miners typically not normal nodes in the sense that they don't relay or propagate transactions to the rest of the network? I mean if I would deliberately send a 'secret' tx to a miner's node (hoping to get that included in the blockchain), wouldn't it get relayed to other nodes as well, thus allowing its presence to be detected on the network?
RocketNuts
CC BY-SA 3.0
2014-04-27T16:35:17.413Z
That's an important distinction to make, and it's subtle.  Yes, miners are typically running "normal" nodes, but remember that miners only typically do things to help the network because it furthers their own self-interest.  If you have an arrangement with miners to pay them some cut of your double-spend gains, then it's to their advantage to keep your transactions secret until they hit the blockchain.  They control the software that they're running, and it's open-source.  Heck, miners already run modified node software.  Eligius implements CPFP, which isn't in standard node software.
Joe Amenta
CC BY-SA 3.0
2014-04-27T18:47:13.237Z
Would it be feasible to connect to such mining pools (or all major mining pools for that matter), just to see what transactions are supposed to be included?
RocketNuts
CC BY-SA 3.0
2014-04-27T19:26:49.247Z
Not really.  If miners are incentivized to secretly favor some transactions over others, then they have no reason to share that information with anyone other than the person who contracted them to include the double-spend transaction.  Even if they did, you would have no reason to trust them.
Joe Amenta
CC BY-SA 3.0
2014-04-27T19:51:16.560Z
Sure, but that would only apply to individual miners, right? Which generally have a *very* small chance of actually mining the next block, in which they're trying to include a secret tx (at the expense of a public tx not getting confirmed). But when checking the transaction data that is being mined by pools, I'd say this should be detectable...? Or is there a way to do pooled or distributed mining (i.e. have many people simultaneously trying to hash a list of transactions, including a secret tx) without actually disclosing the secret tx?
RocketNuts
CC BY-SA 3.0
2014-04-28T09:19:48.530Z
That raises a good point.  While pools generally act as just "one big miner" for most purposes, that's not necessarily true when it comes to keeping a particular transaction a secret.  Without having looked into these protocols in too much detail, you can easily hide a transaction in the data used for stratum or the increasingly obsolete getwork protocols, but with getblocktemplate, it should be impossible for the pool to do this in secret (though individual miners can do this on their own)
Joe Amenta
CC BY-SA 3.0
2014-04-28T09:20:00.537Z
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/14183/discussion-between-joe-amenta-and-rocketnuts)
Joe Amenta
CC BY-SA 3.0
2014-05-23T16:30:28.113Z
@JoeAmenta, But delegating the task to a 3rd party is simply pushing the problem around the table. The question is still valid: How does the 3rd party minimize risk when he accepts zero confirmation payments?
Pacerier
CC BY-SA 3.0
2014-05-24T00:08:10.850Z
@Pacerier, the third-party has a bunch of options at high volume, so long as it's not killing their business.  If that party observes that an average 1% of all transacted volume is lost to double-spends, then they can start charging a flat 1% fee to recoup the losses.  If a particular merchant proves to be problematic, then they can simply drop that merchant (or charge a higher fee if it's just the nature of the merchant's business).
Joe Amenta
CC BY-SA 3.0
2014-05-24T07:02:07.560Z
@JoeAmenta, Good idea on "dynamic fees" there.
Pacerier
CC BY-SA 3.0
2014-10-08T00:25:39.187Z
It's important to note that Coinbase only gives you double-spend protection if you're using their paid "instant-exchange" service which immediately cashes out payments for fiat. If you're keeping the bitcoin in your Coinbase wallet, no such guarantee is provided. (Their documentation is not entirely clear on this, but I just got this clarification from a Coinbase support rep.)
Chris Martin
CC BY-SA 3.0
2015-08-29T11:04:36.300Z
This answer should definitely link/mention the *Have a Snack, Pay with Bitcoins* document, google it
jangorecki
CC BY-SA 3.0
2014-04-27T15:36:53.253Z
2014-04-27T15:51:33.453Z
2020-06-16T11:10:03.350Z
Joe Amenta
<p>I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.</p>

<p>I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)</p>

<ol>
<li>Check if the (unconfirmed) transaction appears on my own node / in my wallet</li>
<li>Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info</li>
<li>Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.</li>
</ol>

<p>If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point? </p>

<p>I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?</p>

CC BY-SA 3.0
2014-04-27T22:24:24.370Z
I'm currently trying to solve the same problem with connecting to as [many nodes](http://bitcoin.stackexchange.com/questions/24932/how-to-make-bitcoind-connect-to-more-nodes) as possible in order to detect a possible double spend in a few seconds. Just to correct your assumption a bit: 3.) a transaction coming from the same input address to a different output address does not necessarily mean double spend if it spends different TXOUTs. Therefore you should only look for transactions spending the same TXOUT, but sending it to a different address.
knaperek
CC BY-SA 3.0
2014-04-29T02:18:35.437Z
For selling a cup of coffee, a soda or sandwiches - I believe other coins (as Ripple, 42coin or even Dogecoin) would be more appropriate for this: I can very well see people waiting for up to 2 minutes, but no more, at which point your risk is enormously reduced.
Joe Pineda
CC BY-SA 3.0
2014-05-02T06:19:14.250Z
@JoePineda Let's just picture that in detail for a moment: You are at your favorite coffee shop, in line to get a cup of coffee and donuts (or similar). Behind you there are five more people waiting. Everyone just wants to grab something and rush on to work. 10 minutes certainly are a no-go, but even two minutes standing there watching half a dozen people grab their stuff and go on with their morning are unacceptable.
Murch
CC BY-SA 3.0
2014-05-03T21:13:02.557Z
Good point! I myself am willing to wait up to about 2 minutes at the counter - once I'm in front of the clerk, that is. But am not willing to spend more than 3 minutes altogether, summing those in line plus at the clerk, and I guess most people wouldn't either :(
Joe Pineda
CC BY-SA 3.0
2014-05-23T16:26:21.193Z
@JoePineda, 10 seconds is the threshold of tolerance. Don't forget that it's not just 10 secs/customer but an **extra** 10 secs/customer, in addition to the 20 seconds we already have to wait while the cashier scans the item.
Pacerier
CC BY-SA 3.0
2014-05-24T08:05:53.787Z
@RocketNuts, What's wrong with BitUndo?
Pacerier
CC BY-SA 3.0
2015-08-29T10:35:06.230Z
@Pacerier it includes in the block a transaction with higher fee, not the first one. That makes them a good processor for double spends.
jangorecki
<wallet><blockchain><confirmations><payment><doublespend>
How to minimize risk when accepting zero confirmation payments?
RocketNuts
# How to minimize risk when accepting zero confirmation payments?

(Asked by: username_0 on 2014-04-27)

I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)

1. Check if the (unconfirmed) transaction appears on my own node / in my wallet
2. Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info
3. Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.

If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?

**Tags:** wallet, blockchain, confirmations, payment, doublespend

> **Comments:**
> **username_1**: I'm currently trying to solve the same problem with connecting to as [many nodes](http://bitcoin.stackexchange.com/questions/24932/how-to-make-bitcoind-connect-to-more-nodes) as possible in order to detect a possible double spend in a few seconds. Just to correct your assumption a bit: 3.) a transaction coming from the same input address to a different output address does not necessarily mean double spend if it spends different TXOUTs. Therefore you should only look for transactions spending the same TXOUT, but sending it to a different address.  
> **username_2**: For selling a cup of coffee, a soda or sandwiches - I believe other coins (as Ripple, 42coin or even Dogecoin) would be more appropriate for this: I can very well see people waiting for up to 2 minutes, but no more, at which point your risk is enormously reduced.  
> **username_3**: @username_2 Let's just picture that in detail for a moment: You are at your favorite coffee shop, in line to get a cup of coffee and donuts (or similar). Behind you there are five more people waiting. Everyone just wants to grab something and rush on to work. 10 minutes certainly are a no-go, but even two minutes standing there watching half a dozen people grab their stuff and go on with their morning are unacceptable.  
> **username_2**: Good point! I myself am willing to wait up to about 2 minutes at the counter - once I'm in front of the clerk, that is. But am not willing to spend more than 3 minutes altogether, summing those in line plus at the clerk, and I guess most people wouldn't either :(  
> **username_4**: @username_2, 10 seconds is the threshold of tolerance. Don't forget that it's not just 10 secs/customer but an **extra** 10 secs/customer, in addition to the 20 seconds we already have to wait while the cashier scans the item.  
> **username_4**: @username_0, What's wrong with BitUndo?  
> **username_5**: @username_4 it includes in the block a transaction with higher fee, not the first one. That makes them a good processor for double spends.  

---

## 2 answers

### Answer by username_7 on 2014-04-27. Score: 6 | Accepted answer

From
<http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13>, here is what services like MyCelium and BitPay may be doing:

> More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.
>
> What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.” This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.

But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender. That's why the blockchain exists in the first place.

One risk of relying on "transaction confidence" is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network. This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.

In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you **or** any of its 0-confirmation inputs could be double-spent, to your detriment.

Frankly, even 1-confirmation transactions aren't risk-free. Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.

If you're serious about trying to minimize the risks of accepting BTC in "real-life" (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation). Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it. Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.

> **Comments:**
> **username_0**: Thanks for the detailed answer. Are miners typically not normal nodes in the sense that they don't relay or propagate transactions to the rest of the network? I mean if I would deliberately send a 'secret' tx to a miner's node (hoping to get that included in the blockchain), wouldn't it get relayed to other nodes as well, thus allowing its presence to be detected on the network?  
> **username_7**: That's an important distinction to make, and it's subtle.  Yes, miners are typically running "normal" nodes, but remember that miners only typically do things to help the network because it furthers their own self-interest.  If you have an arrangement with miners to pay them some cut of your double-spend gains, then it's to their advantage to keep your transactions secret until they hit the blockchain.  They control the software that they're running, and it's open-source.  Heck, miners already run modified node software.  Eligius implements CPFP, which isn't in standard node software.  
> **username_0**: Would it be feasible to connect to such mining pools (or all major mining pools for that matter), just to see what transactions are supposed to be included?  
> **username_7**: Not really.  If miners are incentivized to secretly favor some transactions over others, then they have no reason to share that information with anyone other than the person who contracted them to include the double-spend transaction.  Even if they did, you would have no reason to trust them.  
> **username_0**: Sure, but that would only apply to individual miners, right? Which generally have a *very* small chance of actually mining the next block, in which they're trying to include a secret tx (at the expense of a public tx not getting confirmed). But when checking the transaction data that is being mined by pools, I'd say this should be detectable...? Or is there a way to do pooled or distributed mining (i.e. have many people simultaneously trying to hash a list of transactions, including a secret tx) without actually disclosing the secret tx?  
> **username_7**: That raises a good point.  While pools generally act as just "one big miner" for most purposes, that's not necessarily true when it comes to keeping a particular transaction a secret.  Without having looked into these protocols in too much detail, you can easily hide a transaction in the data used for stratum or the increasingly obsolete getwork protocols, but with getblocktemplate, it should be impossible for the pool to do this in secret (though individual miners can do this on their own)  
> **username_7**: let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/14183/discussion-between-joe-username_7-and-username_0)  
> **username_4**: @username_7, But delegating the task to a 3rd party is simply pushing the problem around the table. The question is still valid: How does the 3rd party minimize risk when he accepts zero confirmation payments?  
> **username_7**: @username_4, the third-party has a bunch of options at high volume, so long as it's not killing their business.  If that party observes that an average 1% of all transacted volume is lost to double-spends, then they can start charging a flat 1% fee to recoup the losses.  If a particular merchant proves to be problematic, then they can simply drop that merchant (or charge a higher fee if it's just the nature of the merchant's business).  
> **username_4**: @username_7, Good idea on "dynamic fees" there.  
> **username_8**: It's important to note that Coinbase only gives you double-spend protection if you're using their paid "instant-exchange" service which immediately cashes out payments for fiat. If you're keeping the bitcoin in your Coinbase wallet, no such guarantee is provided. (Their documentation is not entirely clear on this, but I just got this clarification from a Coinbase support rep.)  
> **username_5**: This answer should definitely link/mention the *Have a Snack, Pay with Bitcoins* document, google it  

---

### Answer by username_6 on 2014-04-27. Score: 0

First of all and most important: do only business with people you trust. That does not mean that you have to have known them for a long period of time, but only that the person that is doing business with you is more likely to optimize his profit if he does not scam you.

I'm not sure about the odds of successfully launching a double spend attack after a x seconds wait, but what you can do is write some software that connects to some of the major mining pools and waits if your transaction (or a malicious double spend attempt transaction) shows up. It would be great if mining pools had a web API for checking which transactions are likely to get included in their next block, but unfortunately they don't. That means that you would have to program such application yourself (I do not know of any existing libraries with this functionality, but enlighten me if they exist).

Finally, you could always work with [green addresses](https://en.bitcoin.it/wiki/Green_address). If your partner agrees in trusting some third party, transactions can be cleared instantaneous.

> **Comments:**
> **username_0**: Good suggestion about connecting to mining pools. Only doing business with people I trust, or green addresses, are not an option, I'm afraid. It's supposed to accept payment from random customers (i.e. complete strangers).  
> **username_6**: Then there is no solution, except to connect to many nodes as possible, and especially to mining pools. Just connect as a dummy node and fetch the block they are working on. AFAIS there is no way the pool can cheat on you, if it is decentralized and open, like P2Pool.  

---

