Time to wait for 99% surety of no double spend, accounting for pool hashrate %

djbooth007

newbie

Activity: 55

Merit: 0

Quote from: gmaxwell on June 26, 2014, 11:40:14 AM

Quote from: djbooth007 on June 26, 2014, 07:18:34 AM

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.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: djbooth007 on June 26, 2014, 07:18:34 AM

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?

djbooth007

newbie

Activity: 55

Merit: 0

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*

fbueller

sr. member

Activity: 412

Merit: 287

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.

djbooth007

newbie

Activity: 55

Merit: 0

Quote from: fbueller on June 25, 2014, 09:58:41 PM

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

Activity: 412

Merit: 287

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

djbooth007

newbie

Activity: 55

Merit: 0

Quote from: DeathAndTaxes on June 25, 2014, 08:13:58 PM

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.

Quote from: fbueller on June 25, 2014, 08:59:29 PM

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

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

Activity: 412

Merit: 287

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

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

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

djbooth007

newbie

Activity: 55

Merit: 0

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?

Topic: Time to wait for 99% surety of no double spend, accounting for pool hashrate % (Read 1163 times)