<p>Perhaps they are referring to the green address technique.  Some exchanges support this now:</p>

<ul>
<li><a href="http://en.bitcoin.it/wiki/Green_address" rel="nofollow noreferrer">http://en.bitcoin.it/wiki/Green_address</a></li>
</ul>

<p>Or they might be referring to the ability to protect against a race attack by listening to many nodes so as to learn of any double spend race attack attempts.  That doesn't eliminate the risk entirely but helps to bring it to a level that the merchant can manage.  There has been progress towards doing this listening with varying results ( <a href="http://www.transactionradar.com" rel="nofollow noreferrer">http://www.transactionradar.com</a> and <a href="http://blockchain.info/double-spends" rel="nofollow noreferrer">http://blockchain.info/double-spends</a> ) but there is no service built yet for merchants that provides transaction monitoring and alerting when double spend attempts are detected:</p>

<ul>
<li><a href="https://bitcoin.stackexchange.com/a/2625/153">https://bitcoin.stackexchange.com/a/2625/153</a></li>
</ul>

CC BY-SA 3.0
2012-03-20T06:29:27.480Z
It should be noted that green addresses can (in the future) be used with a split-key eWallet, with a default transaction sending back to the client in the future, so there's no need to trust an eWallet with your coins to use his green address.
Meni Rosenfeld
CC BY-SA 3.0
2012-03-20T17:00:15.587Z
The consensus on multi-node listening is that it you have to do it to protect against a multi-node double spend attack, but since that's not the most serious double spend attack known, it doesn't change the number of confirmations you need to wait for. That needs to be based on the most serious known attack, the [Finney attack](https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384), which doesn't involve submitting different transactions to different nodes.
David Schwartz
CC BY-SA 3.0
2012-03-20T23:51:05.150Z
But without multi-node listening, the chances that the scammer is successful doing a race attack increase ... maybe to more than 50% even.  That would create such an incentive that the merchant would be forced to discontinue accepting bitcoins.  At least with multi-node listening, the risk can be marginalized down to acceptable levels.
Stephen Gornick
CC BY-SA 3.0
2012-03-20T05:30:08.397Z
2012-03-20T05:37:00.277Z
2017-04-13T12:47:33.743Z
Stephen Gornick
<p>On the bitcointalk forum, <a href="https://bitcointalk.org/index.php?topic=68906.msg804057#msg804057">evoorhees wrote</a>:</p>

<blockquote>
  <p>For a long time people said the "waiting for six confirmations" was a
  significant drawback, but most people understand that problem has been
  almost entirely eradicated.</p>
</blockquote>

<p>and <a href="https://bitcointalk.org/index.php?topic=68906.msg805790#msg805790">Revalin replied</a>:</p>

<blockquote>
  <p>as you mentioned we have an elegant potential solution to the
  confirmation delays, though I haven't seen any moves to actually
  implement it yet</p>
</blockquote>

<p>How has the problem of waiting for confirmations been eradicated?  What is this elegant potential solution?  The first quote seems to imply the problem is already solved, whereas the 2nd says the solution hasn't been implemented yet.  Which is it?</p>

<confirmations>
How has the problem of waiting for confirmations been eradicated?
Chris Moore
# How has the problem of waiting for confirmations been eradicated?

(Asked by: username_0 on 2012-03-20)

On the bitcointalk forum, [evoorhees wrote](https://bitcointalk.org/index.php?topic=68906.msg804057#msg804057):

> For a long time people said the "waiting for six confirmations" was a
> significant drawback, but most people understand that problem has been
> almost entirely eradicated.

and [Revalin replied](https://bitcointalk.org/index.php?topic=68906.msg805790#msg805790):

> as you mentioned we have an elegant potential solution to the
> confirmation delays, though I haven't seen any moves to actually
> implement it yet

How has the problem of waiting for confirmations been eradicated? What is this elegant potential solution? The first quote seems to imply the problem is already solved, whereas the 2nd says the solution hasn't been implemented yet. Which is it?

**Tags:** confirmations


---

## 1 answers

### Answer by username_1 on 2012-03-20. Score: 5 | Accepted answer

Perhaps they are referring to the green address technique. Some exchanges support this now:

* <http://en.bitcoin.it/wiki/Green_address>

Or they might be referring to the ability to protect against a race attack by listening to many nodes so as to learn of any double spend race attack attempts. That doesn't eliminate the risk entirely but helps to bring it to a level that the merchant can manage. There has been progress towards doing this listening with varying results ( <http://www.transactionradar.com> and <http://blockchain.info/double-spends> ) but there is no service built yet for merchants that provides transaction monitoring and alerting when double spend attempts are detected:

* <https://bitcoin.stackexchange.com/a/2625/153>

> **Comments:**
> **username_2**: It should be noted that green addresses can (in the future) be used with a split-key eWallet, with a default transaction sending back to the client in the future, so there's no need to trust an eWallet with your coins to use his green address.  
> **username_3**: The consensus on multi-node listening is that it you have to do it to protect against a multi-node double spend attack, but since that's not the most serious double spend attack known, it doesn't change the number of confirmations you need to wait for. That needs to be based on the most serious known attack, the [Finney attack](https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384), which doesn't involve submitting different transactions to different nodes.  
> **username_1**: But without multi-node listening, the chances that the scammer is successful doing a race attack increase ... maybe to more than 50% even.  That would create such an incentive that the merchant would be forced to discontinue accepting bitcoins.  At least with multi-node listening, the risk can be marginalized down to acceptable levels.  

---

