djbooth007 (OP)
Newbie
Offline
Activity: 55
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 12:30:50 AM |
|
I need some maths whiz help. I'm trying to work out the time required to wait for 99% surety of no double spend, based on the current block time and an estimate of mining pool hashrate %. eg, if DingBatPool has X% of the network hashrate and the block time is Y minutes, you should wait Z minutes to be 99% certain there is no double spend. [for now, let's ignore that Pool1, Pool2, etc could be colluding] Data from: https://blockchain.info/q/interval [Block time] https://blockchain.info/pools?timespan=4hrs [inaccurate, but sufficient pool hashrate %] What would be the formula to get Z = the time required to wait?
|
|
|
|
|
|
Even in the event that an attacker gains more than 50% of the network's
computational power, only transactions sent by the attacker could be
reversed or double-spent. The network would not be destroyed.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 01:13:58 AM |
|
Time is irrelevant. All that matters is confirmations (blocks). This doesn't give you exactly what you are looking for but it provides a different context (the cost to perform the attack). https://bitcoil.co.il/Doublespend.pdf
|
|
|
|
fbueller
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 01:59:29 AM |
|
The timestamp in blocks can be interfered with, so what happens if someone puts a block 20m forward in time? Would this cause your app to trust all transactions for the next 10 minutes? As DeathByTaxes said, confirmations are where it counts. Satoshi's whitepaper has C++ code to determine the % likelyhood of an attacker being able to orphan a transaction with n confirmations by producing a chain with greater difficulty than the present one.. You need to wait 3 confirmations for ~99% certainty the chain wont be orphaned (if the attacker controls 10% of the hashrate - 15 confirmations if they control 30!) So this could be exactly what you need ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Given a hashrate that you get from blockchain, continue calculating the percentage likelyhood an attacker can orphan a transaction X blocks deep, and stop when your probability is 0.01 - X is now the number of confirmations needed or 99% certainty. Multiply this by the current average block time (from blockchain) and you have your answer.
|
Bitwasp Developer.
|
|
|
djbooth007 (OP)
Newbie
Offline
Activity: 55
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 02:31:42 AM |
|
Time is irrelevant.
For User Interface design, time is the only value displayed. Users dont care for nor understand confirmations, but I get your point. Estimating **if** a transaction will be accepted into the next block is part of the challenge. The timestamp in blocks can be interfered with, so what happens if someone puts a block 20m forward in time? Would this cause your app to trust all transactions for the next 10 minutes? As DeathByTaxes said, confirmations are where it counts. Satoshi's whitepaper has C++ code to determine the % likelyhood of an attacker being able to orphan a transaction with n confirmations by producing a chain with greater difficulty than the present one.. You need to wait 3 confirmations for ~99% certainty the chain wont be orphaned (if the attacker controls 10% of the hashrate - 15 confirmations if they control 30!) So this could be exactly what you need ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Given a hashrate that you get from blockchain, continue calculating the percentage likelyhood an attacker can orphan a transaction X blocks deep, and stop when your probability is 0.01 - X is now the number of confirmations needed or 99% certainty. Multiply this by the current average block time (from blockchain) and you have your answer. Thanks, I'll give it a whirl.
|
|
|
|
|
djbooth007 (OP)
Newbie
Offline
Activity: 55
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 04:01:41 AM |
|
Absolutely brilliant! You've saved me a fair amount of head scratching! Interesting (disappointing?) to see that 5.3 hours is the wait time due to Ghash.
|
|
|
|
fbueller
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 11:24:52 AM |
|
No probs! Yeah it really isn't great. This output should show you the fears behind a 51% attack. https://pastebin.com/5vbrHvaqa. It calculates the probably of catching up from 5% of the hashrate, to 100%. Naturally, beyond 50% it's statistically likely an attacker is able to catch up, and orphan the current best chain. I think it's pretty clear pools shouldn't be allowed to exceed 30% or perhaps even lower.. If someone has 30%, we need to wait 13 confirmations for a 1% certainty the transaction cannot be reversed, but at 35% this becomes 24, and the situation gets worse and worse. People shouldn't only panic just when a pool reaches 51%.. At that point, it's an absolute certainty the pool could orphan the chain if they wanted. 51% just triggers wild panic, but if people wanted to be proactive, now is the time to try fix the protocol - not when someone finally accumulates the hashrate to do what the like.
|
Bitwasp Developer.
|
|
|
djbooth007 (OP)
Newbie
Offline
Activity: 55
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 12:18:34 PM |
|
Mike Hearn was saying recently that ONLY Gavin was working on protocol stuff, mostly focusing on floating fees. Any major changes to the core protocol will happen very slowly if that's the case.
There's only a dozen major pools. Would be nice to have 50+ pools where one does not exceed 10% share in order to avoid a protocol-based solution. Seems a far way off, unfortunately.
GHash have proven there is a valid business model that other pools can adopt and erode GHash's share. *fingers crossed*
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4172
Merit: 8419
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 04:40:14 PM |
|
Mike Hearn was saying recently that ONLY Gavin was working on protocol stuff, mostly focusing on floating fees.
If Mike actually said that he's confused (and heck, floating fees isn't even a protocol thing— it's wallet behavior). GHash have proven there is a valid business model that other pools can adopt and erode GHash's share. *fingers crossed* And what business model do you think they have?
|
|
|
|
djbooth007 (OP)
Newbie
Offline
Activity: 55
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2014, 11:37:31 PM |
|
Mike Hearn was saying recently that ONLY Gavin was working on protocol stuff, mostly focusing on floating fees.
If Mike actually said that he's confused (and heck, floating fees isn't even a protocol thing— it's wallet behavior). GHash have proven there is a valid business model that other pools can adopt and erode GHash's share. *fingers crossed* And what business model do you think they have? Hi Greg, I certainly dont want to put words in Mike's mouth. That was the impression I got from a recent interview : http://zz.reddit.com/r/Bitcoin/comments/28zts3/mike_hearn_interview_quotes_progress_on_the/I have no opinion on CEX / GHash business model, but to gain such a majority of the network, they have done *something* to convince a large chunk of mining investment to use their operations.
|
|
|
|
|