Bitcoin Forum
December 18, 2017, 12:14:18 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Time to wait for 99% surety of no double spend, accounting for pool hashrate %  (Read 1030 times)
djbooth007
Jr. Member
*
Offline Offline

Activity: 55


mmm... bitcoins


View Profile WWW
June 26, 2014, 12:30:50 AM
 #1

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?

1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
1513556058
Hero Member
*
Offline Offline

Posts: 1513556058

View Profile Personal Message (Offline)

Ignore
1513556058
Reply with quote  #2

1513556058
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 26, 2014, 01:13:58 AM
 #2

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
Sr. Member
****
Offline Offline

Activity: 412


View Profile
June 26, 2014, 01:59:29 AM
 #3

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 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
Jr. Member
*
Offline Offline

Activity: 55


mmm... bitcoins


View Profile WWW
June 26, 2014, 02:31:42 AM
 #4

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 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.

fbueller
Sr. Member
****
Offline Offline

Activity: 412


View Profile
June 26, 2014, 02:58:41 AM
 #5

I've started already! https://bitwasp.co/block_hashrate.php

So basically, I'm doing as I described above.. Get pools % hashrate, determine based on their hashrate how many blocks deep a transaction must be so that pool to have less than 1% probability of producing a greater difficulty chain..


code's here if that's any use to you, PHP: https://gist.github.com/afk11/bbd9657b91e9a68d054f


Bitwasp Developer.
djbooth007
Jr. Member
*
Offline Offline

Activity: 55


mmm... bitcoins


View Profile WWW
June 26, 2014, 04:01:41 AM
 #6

I've started already! https://bitwasp.co/block_hashrate.php

So basically, I'm doing as I described above.. Get pools % hashrate, determine based on their hashrate how many blocks deep a transaction must be so that pool to have less than 1% probability of producing a greater difficulty chain..


code's here if that's any use to you, PHP: https://gist.github.com/afk11/bbd9657b91e9a68d054f

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
Sr. Member
****
Offline Offline

Activity: 412


View Profile
June 26, 2014, 11:24:52 AM
 #7

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
Jr. Member
*
Offline Offline

Activity: 55


mmm... bitcoins


View Profile WWW
June 26, 2014, 12:18:34 PM
 #8

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
*
qt
Offline Offline

Activity: 2366



View Profile
June 26, 2014, 04:40:14 PM
 #9

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).

Quote
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?

Bitcoin will not be compromised
djbooth007
Jr. Member
*
Offline Offline

Activity: 55


mmm... bitcoins


View Profile WWW
June 26, 2014, 11:37:31 PM
 #10

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).

Quote
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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!