<p>One way would be to modify the bitcoin client. The modification would change mempool so that you have a good mempool, and a bad mempool.</p>

<p>Normal transactions go in the good mempool. However, if you notice a transaction that spends an output that is already spent in another loose transaction, then it goes into the bad mempool.</p>

<p>The bad mempool is never relayed to other clients that don't have good/bad mempools, and never mined from. </p>

<p>It is relayed to other bad mempools, and if those see a transaction that double-spends one of their transactions, then it would alert the user.</p>

CC BY-SA 3.0
2017-07-19T14:05:55.900Z
How could you ensure that, between the two transactions, most clients would make the same choice (ie flag the same duplicate as bad)? IMHO it would slow the propagation without adding security. In such cases, it may event be interesting to over-broadcast both transactions to ensure miners will be able to detect the glitch
PPC
CC BY-SA 3.0
2017-07-19T17:22:26.233Z
@PPC You can't, not without some objective way of measuring which transaction was first. Something like, say, putting the transaction in a blockchain. However, nodes don't need to come to global agreement about which came first. If one of your peers says 'look at these two conflicting transactions,' the fact that they got the order wrong doesn't matter: you still know there's a double-spend afoot.
Nick ODell
CC BY-SA 3.0
2013-04-19T17:41:28.960Z
2013-04-19T17:41:28.960Z
Nick ODell
<p>Because of the way the Bitcoin protocol with the distributed and decentralized P2P network is architected, monitoring the way you describe would do more harm than good.</p>

<p>If a merchant is expecting to learn of double spends, then the monitoring service needs to know of each transaction.   A race attack double spend attempt might, however, communicate one transaction that reaches the merchant but a different transaction that reaches the miner that happens to include that transaction in a block.    If the monitoring service sees what the miner sees, then the monitoring service would never know that the merchant had received a transaction that eventually became invalid due to the later transaction from a mined block.</p>

<p>So a merchant that is following the DIY route has further exposure to double spends.  </p>

<p>Some payment processors will deliver if a 0/unconfirmed notice was sent and then later that transaction becomes invalid due to a double spend.  BitPay is, I believe, one of them that will do this.</p>

<p>There is a need for some more utilities for aiding merchants, including transaction re-broadcast.  So for example if a merchant accepts a 0/unconfirmed transaction that transaction gets rebroadcast sufficiently even if the original sender fails to re-broadcast it.  Also needed might be a service that tries to ensure that if there is a blockchain fork (two or more chains both at the same height) that the confirmed transactions from one side are relayed to miners still working on the other side of the fork.</p>

<p>The reason these haven't already been built is that there are so few merchants currently who accept payment on 0/unconfirmed transactions.  There will need to be some double spending thefts to raise awareness that this is a risk not to be ignored, especially for those merchants following the DIY path. </p>

CC BY-SA 3.0
2013-04-19T13:54:15.427Z
Ok. So a part of the problem with setting up such a service, is that the service might have received the double spend (seen from the merchant's point of view) and rejected the transaction that the merchant has accepted. But what if we restructure our hypothetical web service (that informs about double spends), so that the merchant includes the transaction (base64-encoded, for example) in a POST request to the web service? Would this work then? "Are you aware of any transactions that try to spend the same inputs as this transaction does?" would then be the question.
runeks
CC BY-SA 3.0
2013-04-19T04:18:31.470Z
2013-04-19T04:18:31.470Z
Stephen Gornick
<p>I often come across merchants accepting payment in bitcoin, who require several confirmations on transactions, but where the probability of a successful double spend doesn't justify the waiting time for the user. A good example is membership payment for adult sites, where the membership can easily be withdrawn in case of a double spend, and not much is lost if a double spend is successful.</p>

<p>A part of the reason they do this, I think, is that they don't have a good way of knowing if a user is attempting to double spend coins sent to them.</p>

<p>Is there a service available that allows merchants to be notified of double spends of coins sent to them, so that they can be notified in case this happens, and take action - for example by banning the user, or just temporarily removing the deposit to an account until the transaction has 6 confirmations?</p>

<p>A simple service could be one where the merchant enters their deposit address at a web service, and the web service simply responds with the amount of attempted double spends, ie. if any of the inputs to the transaction that sends funds to the merchant's deposit address are attempted spent in another transaction, the request will return a number above 0.</p>

<p>Does such a service exist?</p>

CC BY-SA 3.0
2014-09-15T16:15:26.847Z
See:
http://dev.blockcypher.com/reference.html#zero_confirmations
Matthieu
<services><doublespend><merchant-services>
Is there a service that alerts about attempted double spends for merchants accepting 0-confirmation transactions?
runeks
# Is there a service that alerts about attempted double spends for merchants accepting 0-confirmation transactions?

(Asked by: username_0 on 2013-04-19)

I often come across merchants accepting payment in bitcoin, who require several confirmations on transactions, but where the probability of a successful double spend doesn't justify the waiting time for the user. A good example is membership payment for adult sites, where the membership can easily be withdrawn in case of a double spend, and not much is lost if a double spend is successful.

A part of the reason they do this, I think, is that they don't have a good way of knowing if a user is attempting to double spend coins sent to them.

Is there a service available that allows merchants to be notified of double spends of coins sent to them, so that they can be notified in case this happens, and take action - for example by banning the user, or just temporarily removing the deposit to an account until the transaction has 6 confirmations?

A simple service could be one where the merchant enters their deposit address at a web service, and the web service simply responds with the amount of attempted double spends, ie. if any of the inputs to the transaction that sends funds to the merchant's deposit address are attempted spent in another transaction, the request will return a number above 0.

Does such a service exist?

**Tags:** services, doublespend, merchant-services

> **Comments:**
> **username_1**: See: http://dev.blockcypher.com/reference.html#zero_confirmations  

---

## 2 answers

### Answer by username_4 on 2013-04-19. Score: 5 | Accepted answer

Because of the way the Bitcoin protocol with the distributed and decentralized P2P network is architected, monitoring the way you describe would do more harm than good.

If a merchant is expecting to learn of double spends, then the monitoring service needs to know of each transaction. A race attack double spend attempt might, however, communicate one transaction that reaches the merchant but a different transaction that reaches the miner that happens to include that transaction in a block. If the monitoring service sees what the miner sees, then the monitoring service would never know that the merchant had received a transaction that eventually became invalid due to the later transaction from a mined block.

So a merchant that is following the DIY route has further exposure to double spends.

Some payment processors will deliver if a 0/unconfirmed notice was sent and then later that transaction becomes invalid due to a double spend. BitPay is, I believe, one of them that will do this.

There is a need for some more utilities for aiding merchants, including transaction re-broadcast. So for example if a merchant accepts a 0/unconfirmed transaction that transaction gets rebroadcast sufficiently even if the original sender fails to re-broadcast it. Also needed might be a service that tries to ensure that if there is a blockchain fork (two or more chains both at the same height) that the confirmed transactions from one side are relayed to miners still working on the other side of the fork.

The reason these haven't already been built is that there are so few merchants currently who accept payment on 0/unconfirmed transactions. There will need to be some double spending thefts to raise awareness that this is a risk not to be ignored, especially for those merchants following the DIY path.

> **Comments:**
> **username_0**: Ok. So a part of the problem with setting up such a service, is that the service might have received the double spend (seen from the merchant's point of view) and rejected the transaction that the merchant has accepted. But what if we restructure our hypothetical web service (that informs about double spends), so that the merchant includes the transaction (base64-encoded, for example) in a POST request to the web service? Would this work then? "Are you aware of any transactions that try to spend the same inputs as this transaction does?" would then be the question.  

---

### Answer by username_2 on 2013-04-19. Score: 1

One way would be to modify the bitcoin client. The modification would change mempool so that you have a good mempool, and a bad mempool.

Normal transactions go in the good mempool. However, if you notice a transaction that spends an output that is already spent in another loose transaction, then it goes into the bad mempool.

The bad mempool is never relayed to other clients that don't have good/bad mempools, and never mined from.

It is relayed to other bad mempools, and if those see a transaction that double-spends one of their transactions, then it would alert the user.

> **Comments:**
> **username_3**: How could you ensure that, between the two transactions, most clients would make the same choice (ie flag the same duplicate as bad)? IMHO it would slow the propagation without adding security. In such cases, it may event be interesting to over-broadcast both transactions to ensure miners will be able to detect the glitch  
> **username_2**: @username_3 You can't, not without some objective way of measuring which transaction was first. Something like, say, putting the transaction in a blockchain. However, nodes don't need to come to global agreement about which came first. If one of your peers says 'look at these two conflicting transactions,' the fact that they got the order wrong doesn't matter: you still know there's a double-spend afoot.  

---

