8

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.

Improve this question
3
  • 2
    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
    Commented May 21, 2016 at 21:21
  • 3
    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 (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
    Commented May 22, 2016 at 1:58
  • 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
    Commented May 22, 2016 at 4:19

1 Answer 1

Reset to default
3

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.