<p>Pools can lie about their hashrate, and not claim to have solved blocks that were actually solved by them when. I would propose that this is the wrong method of dynamically choosing a confirm count.</p>

<p>Instead, my suggestion would be to dynamically set your threshold based on the value of the transaction. If someone buys a $1 digital good, you can send it to them immediately, because the loss of a double-spend is almost immeasurably small (it's a digital good anyway). If someone buys a $50 item that needs to physically be shipped, you can wait for 1 confirm before getting the item off the shelf and popping it in a box. And if someone buys a $100 000 sports car, well the paperwork will at least take a few hours to fill out and complete, maybe even a day or two, so you'll have worked through enough confirms to be reasonably sure of the safety of that transaction.</p>

<p>Right now I don't believe there is a merchant solution that does this, but it is somewhat trivial to build.</p>

CC BY-SA 3.0
2016-05-22T08:24:35.607Z
2016-05-22T08:24:35.607Z
fluffyponyza
<p>Satoshi built Bitcoin to be a decentralized network. Some of the original recommendations (such as waiting for 6 confirmations) relied on statistics that related to level of decentralization.</p>

<p><a href="https://bitcoin.org/bitcoin.pdf">https://bitcoin.org/bitcoin.pdf</a></p>

<p>According to the math on page 9 of the whitepaper there is less than a 0.1% chance of successful a double spending attack if a rogue miner controls 10% of the network hash rate and the recipient waits for 5 confirmations. However if a rogue miner controls 45% of the network hash rate you would have to wait for 340 confirmations to reach the same level of confidence (less than 0.1% chance) of a double spend not occurring.</p>

<p>Are there any tools that automatically monitor the hashrate of the major pools and dynamically use that data to change the number of confirmations merchants request? My intended use case would kick in for large purchases when/if a major pool went down, giving another pool (at least temporarily) a very large percentage of the network hash rate.</p>

CC BY-SA 3.0
2016-05-21T21:21:33.480Z
Though this idea is intellectually interesting, it sounds like overkill and too complicated to implement for practical use and thus it is **very** unlikely to exist.
Mikko Ohtamaa
CC BY-SA 3.0
2016-05-22T01:58:33.817Z
Not only is it overkill, it's meaningless. The dynamics of this are simply not understood well enough for such a tool to give sensible results. Papers like my own (https://bitcoil.co.il/Doublespend.pdf) and those of others like Aviv Zohar shed some light on this, but given the fact that, AFAIK, there has never been any case of hashrate-based double spend, it's all just theoretical talk about a problem that doesn't yet exist.
Meni Rosenfeld
CC BY-SA 3.0
2016-05-22T04:19:37.537Z
Another reason it's meaningless is you'd be getting that information from a centralized website somewhere, while miners are (can be) anonymous and most are currently only voluntarily sharing their identities anyway.
Jannes
<mining-pools><hashpower><doublespend>
Merchant tool that will dynamically adjust the # of required confirmations based on network hashrate data
studycrypto
# Merchant tool that will dynamically adjust the # of required confirmations based on network hashrate data

(Asked by: username_0 on 2016-05-21)

Satoshi built Bitcoin to be a decentralized network. Some of the original recommendations (such as waiting for 6 confirmations) relied on statistics that related to level of decentralization.

<https://bitcoin.org/bitcoin.pdf>

According to the math on page 9 of the whitepaper there is less than a 0.1% chance of successful a double spending attack if a rogue miner controls 10% of the network hash rate and the recipient waits for 5 confirmations. However if a rogue miner controls 45% of the network hash rate you would have to wait for 340 confirmations to reach the same level of confidence (less than 0.1% chance) of a double spend not occurring.

Are there any tools that automatically monitor the hashrate of the major pools and dynamically use that data to change the number of confirmations merchants request? My intended use case would kick in for large purchases when/if a major pool went down, giving another pool (at least temporarily) a very large percentage of the network hash rate.

**Tags:** mining-pools, hashpower, doublespend

> **Comments:**
> **username_1**: Though this idea is intellectually interesting, it sounds like overkill and too complicated to implement for practical use and thus it is **very** unlikely to exist.  
> **username_2**: Not only is it overkill, it's meaningless. The dynamics of this are simply not understood well enough for such a tool to give sensible results. Papers like my own (https://bitcoil.co.il/Doublespend.pdf) and those of others like Aviv Zohar shed some light on this, but given the fact that, AFAIK, there has never been any case of hashrate-based double spend, it's all just theoretical talk about a problem that doesn't yet exist.  
> **username_3**: Another reason it's meaningless is you'd be getting that information from a centralized website somewhere, while miners are (can be) anonymous and most are currently only voluntarily sharing their identities anyway.  

---

## 1 answers

### Answer by username_4 on 2016-05-22. Score: 3 | Accepted answer

Pools can lie about their hashrate, and not claim to have solved blocks that were actually solved by them when. I would propose that this is the wrong method of dynamically choosing a confirm count.

Instead, my suggestion would be to dynamically set your threshold based on the value of the transaction. If someone buys a $1 digital good, you can send it to them immediately, because the loss of a double-spend is almost immeasurably small (it's a digital good anyway). If someone buys a $50 item that needs to physically be shipped, you can wait for 1 confirm before getting the item off the shelf and popping it in a box. And if someone buys a $100 000 sports car, well the paperwork will at least take a few hours to fill out and complete, maybe even a day or two, so you'll have worked through enough confirms to be reasonably sure of the safety of that transaction.

Right now I don't believe there is a merchant solution that does this, but it is somewhat trivial to build.


---

