Luke Jr's HARDFORK proposal debunked

[Preclus]

Danny, I liked your explanation so much I figured I'd take a couple minutes to code it up so others can play with it. I wrote it in Go so you can just run the code online. You can change the number of players to see how it affects the winning round.

There's only two things to look out for. One is that Google won't allow too many iterations. If you set NUM_TOTAL_GAMES too large, it will complain it is taking too long. Also, if you run the program and then run it again without modifying anything, the answer won't change because Google just gives you the same answer as the last time if the code isn't changed. You need to change a variable or something to get it to actually run the program again.

You will see your math matches up with the output which is what would be expected.

https://play.golang.org/p/uoWEBnjMss

[1714958311]

1714958311

[1714958311]

1714958311

[1714958311]

1714958311

[hhanh00]

I think the calculations are slightly incorrect though.

1. The probability of rolling 1/1/1/1 on 4 dices is 1/6^4 = 1/1296. OK
2. If 20 people are rolling at the same time, the probability of having a winner in a round isn't 20/1296.
It's 1-(1-1/1296)^20 = 0.01531949966668002983951097896119
Instead of 20/1296 = 0.01543209876543209876543209876543
3. If each round has a probability p of finishing the game and every round is independent, the expected number of rounds of the game is 1/p.
This is true, but not obvious. I put a proof below.

The average duration of the game is 65.28 s (vs 64.8 ).

In the case of bitcoin, the difference is negligible since it's in the order of p^2.

--h







PS
Call E(i) the expected number of rounds of this game assuming that we got to round i and not counting the previous rounds.
At round i, we stop with probability p and continue with proability 1-p.
So there are two possibilities:
  - the game lasts 1 more round with probability p because we got 1/1/1/1.
  - or it continues for 1 + E(i+1) rounds with probability 1-p because we didn't.

E(i) = p x 1 + (1-p) x (1 + E(i+1))

Now the important thing is that the game is 'memoryless'. So E(i) doesn't change. E(i) = E(i+1) = E

E = p + (1-p)(1+E)
which leads to E = 1/p.

[DannyHamilton]

The average duration of the game is 65.28 s (vs 64.8 ).

In the case of bitcoin, the difference is negligible since it's in the order of p^2.

This occurs because we are defining a 1 second "turn" as 20 simultaneous rolls of the dice.  Remember this is actually intended to be an analogy for mining where there is no neatly defined "turn" during which the participants all attempt X simultaneous hashes.  Instead each and every hash is a distinct and separate event.  Therefore, instead of calculating the probability for 20 simultaneous rolls, calculate the odds for 1 roll and assume that there is a separation of 1/20 of a second between players rolling within a "turn".  Assume that once one player in a "turn" gets four 1's simultaneously, the rest of the players that would have rolled after the "winner" in that second don't bother rolling their dice (since a "winner" for that round has already been found).  I left this complication out of the analogy because people were already having a hard enough time with the math, but I think you'll find that the 64.8 seconds is the correct number.

There are a few other "complications" that were left out of the analogy as well, because the analogy was really only intended to demonstrate that cutting the total network hash power in half would have the effect of doubling the time between solutions.

To make this intuitive, rather than messing around with math, consider what you think would happen if 1 person controlled all the hash power in the world, and shut off half of his hash power.  The OP obscures the reality by splitting the hash power up between participants and pretending that the fact that there are different people doing the hashing makes a difference in the results. In reality, the hash power doesn't know anything about who is running it.  I *think* that most people will realize that if a single person cuts their own hash power in half, then they will take twice as long on average between blocks that they personally solve.  If we think of the entire bitcoin network as a single hashing entity (and the miners and pools are simply maintaining the equipment for that single global entity), then it should be intuitive that an instantaneous cutting in half of the global hash power will result in a doubling of the time between blocks (until the difficulty adjusts).

PS
Call E(i) the expected number of rounds of this game assuming that we got to round i and not counting the previous rounds.
- snip -
E = p + (1-p)(1+E)
which leads to E = 1/p.

If I followed your math correctly, I think you're pointing out the interesting fact that the remaining average time is always 64.8 seconds regardless of how long a round has been going on.  In other words, if you've been playing for 60 seconds and you don't yet have a "winner", the average amount of time left is still 64.8 more seconds (not 4.8 seconds).  If you've been playing for 180 seconds, and you don't yet have a "winner", the average amount of time left is still 64.8 more seconds.

[monsterer]

PS
Call E(i) the expected number of rounds of this game assuming that we got to round i and not counting the previous rounds.
- snip -
E = p + (1-p)(1+E)
which leads to E = 1/p.

If I followed your math correctly, I think you're pointing out the interesting fact that the remaining average time is always 64.8 seconds regardless of how long a round has been going on.  In other words, if you've been playing for 60 seconds and you don't yet have a "winner", the average amount of time left is still 64.8 more seconds (not 4.8 seconds).  If you've been playing for 180 seconds, and you don't yet have a "winner", the average amount of time left is still 64.8 more seconds.

That simply says that the 'expectation' is the inverse of the probability of each roll. This is otherwise known as the mining difficulty, or expected number of hashes to solve a block.

[franky1]

my point is. if your using "averages"  and then you took an even 50% of the average then yes you would see a double

but randomness is not averaged

for instance the dice game.
you may throw it 1296 times but you *may* never get 1 1 1 1
you might however get 1 5 2 6 on three different occassions
or another random combination several times. but no guarantee of 1 1 1 1

you are only guaranteed to get it if you dont treat it like random throws but more of a combination look
6666, 6665, 6664...
instead of
4625, 2153,2256....

also trying to suggest that an average is a hard rule and use that along with a doubler is wrong.
just like saying bitcoin only makes blocks in 10 minutes which turns into 20 minutes is wrong.

the 10minutes is not based on the combined work of the 20 pools. but based on the work of 1 pool who luckily beat his 19 competitors
the 2nd place competitor could easily have got a solution just 2 seconds later.. should the first winner not have solved first (not 10 minutes later)

but the reality is a few blocks have been found in 1 minute of each other(402068-402069) meaning that if slushpool had half the hash power instead, it still would not mean it solved that block in 2 minutes instead of 1 (again not quite).
because hashrate is not even or average, and doesnt account for a competitor who may have a separate solution in 1minute 20 seconds.

EG
F2pool found a block in 7 minutes and then again in 2 minutes. doesnt mean if they had half the hashrate. it could be 14 minutes and 4 minutes(again not quite).

because lets say antpool. making blocks in 1 minute. got kicked off the network. along with eligius pool making 1 block a day. along with bitminter.. and ghash.io.

would any of them impacted BTCC's attempt.. how about F2pools attempt. how about slushes attempts

infact without antpool we could easily have seen F2pool make a block more often in 8-12 minutes because his competition has gone away and no need to stale the attempt mid way.

so the averages and reality do not sit side by side.

infact if BTCC disapears and F2pool disapeared. then antpool would have less competition and able to make more blocks more often all averaging under 10 minutes with the occassional gap to let Bitfury and BW a chance

[DannyHamilton]

my point is. if your using "averages"  and then you took an even 50% of the average then yes you would see a double

Correct.

but randomness is not averaged

Yes, it is.

for instance the dice game.
you may throw it 1296 times but you *may* never get 1 1 1 1
you might however get 1 5 2 6 on three different occassions
or another random combination several times. but no guarantee of 1 1 1 1

Correct.  On average the 1 1 1 1 will come up once every 1296 rolls.  Sometimes it will only take a few rolls, sometimes it will take more than 5184 rolls.

you are only guaranteed to get it if you dont treat it like random throws but more of a combination look
6666, 6665, 6664...
instead of
4625, 2153,2256....

Correct.  Every roll has a 0.077% chance of being 1 1 1 1.

This is how bitcoin mining works.  Every hash is an independent random result.  You might get a winning hash result on your first try.  It might take you more than 3122524100000000000000 tries. But with the current difficulty today the average number of tries is about 780631020000000000000.  You are not guaranteed to EVER get a winning hash.

also trying to suggest that an average is a hard rule and use that along with a doubler is wrong.

I don't understand what you are trying to say here.

Average is an average, and if you cut the number of atempts per unit of time in half, then the average amount of time doubles. That's how math works.

just like saying bitcoin only makes blocks in 10 minutes which turns into 20 minutes is wrong.

Bitcoin averages 10 minutes per block at current difficulty.  If the difficulty stays the same and the hash power is cut in half, then bitcoin will average 20 minutes per block until the next difficulty adjustment.

the 10minutes is not based on the combined work of the 20 pools. but based on the work of 1 pool who luckily beat his 19 competitors

Nope.  The 10 minutes is based on the combined work of all the hash power in the whole world.

the 2nd place competitor could easily have got a solution just 2 seconds later.. (not 10 minutes later)

Or 3 hours later.  The end result of averaging all the possibilities is that (for a given difficulty) if the hash power is cut in half then the average time doubles.

but the reality is a few blocks have been found in 1 minute of each other(402068-402069)

And others have taken more than an hour.

meaning that if slushpool had half the hash power instead, would have solved that block in 2 minutes(again not quite).
F2pool found a block in 7 minutes and then again in 2 minutes. meaning if they had half the hashrate. it could be 14 minutes and 4 minutes(again not quite).

Correct.

however. lets say antpool. making blocks in 1 minute. got kicked off the network. along with eligius pool making 1 block a day. along with bitminter.. and ghash.io.

would any of them impacted BTCC's attempt.. how about F2pools attempt.

Nope, but there would be a lot more blocks that take more than 10 minutes and a lot less blocks that take less than 10 minutes since none of antpool's, eligius', bitminter's, or ghash.io's shorter blocks would exist to step in during those times when BTCC and F2Pool take more than 10 minutes.

infact without antpool we could easily have seen F2pool make a block in 8-12 minutes because his competition has gone away and no need to stale the attempt mid way.

Or we could see a 45 minute block because none of the competition was there to solve a block sooner.

so the averages and reality do not sit side by side.

Averages and reality do sit side-by-side.  Unfortunately you are having a difficult time grasping how it works no matter how we try to explain it.

infact if BTCC disapears and F2pool disapeared. then antpool would have less competition and able to make more blocks

Yes.  All those blocks that take would have taken a longer amount of time will get paid to antpool eventually instead of BTCC and F2Pool.  It will take longer for it to happen, but they will get a larger percentage of the total number of blocks in a difficulty period.

more often

Nope.  Not more often.  It will take longer (since nobody else wins sooner).

all averaging under 10 minutes with the occassional gap to let Bitfury and BW a chance

Nope.  All averaging more than 10 minutes (until the difficulty adjusts) with the occasional even longer gap.  Meanwhile BitFury and BW will occasionally get lucky and get their block first.

[monsterer]

The way blocks are solved is probabilistic and it's actually quite simple:

1. There is a fixed probability of solving a block in one hash, that is  = 1/difficulty
2. Difficulty is the expected number of hashes required to solve a block on average
3. Number of hashes per second is the speed at which you can roll the 'dice'

So, if you have a difficulty of 100, solving it in one hash has a probability p = 1/100, and on average it'll take 100 hashes to solve it.

If you have a hash rate of 10 hashes/s, it'll take 10 seconds to solve on average.

If you halve the difficulty to 50, solving it in one hash p=1/50, on average takes 50 hashes to solve and at 10 hashes/s, it'll take 5 seconds on average to solve.

The bitcoin network as a whole has a hash-rate of H hashes per second, bitcoin's difficulty is adjusted such that solving a block takes a hash-rate of H 10 minutes to solve on average.

[Preclus]

I'll explain Danny's answer in a different way. What he stated was that the times in the cells in the original table weren't representative of the data set described.

He then gave an example of rolling 4 dice and how the average time is affected when the players are halved in that game. To further explain his answer, I created a program to generate the same type of data franky generated in the original post but with actual data from the 4 dice game Danny described. The Go program to generate the data is here so you can play with it if you want. You can just press Run to run the program and see the data:

https://play.golang.org/p/piIbg8DLv3

The program has 20 players (shown by row) throwing 4 dice at a time until they get all 1s. Each player does this 25 times (shown by column) and the number of rounds it took them to roll all 1s is displayed in each cell (if you cut and paste it into a spreadsheet).

After cutting and pasting it into a spreadsheet, here is what the result looks like:

http://s23.postimg.org/jvpcsrn8q/20players.jpg

I then highlighted the winning round (lowest number of rounds to get four 1s) in each column in green.

The average of all the lowest rounds in that table is 58.84.

I then took just the first 10 rows from the spreadsheet:

http://s15.postimg.org/5ihhpq0rd/10players.jpg
 
And highlighted the new winning rounds in yellow. The average of all those lowest rounds is 114.56 which is just about double the previous average.

You should be able to take any 10 rows from the original 20 rows and get similar results, the average will be around double even in this small set.

This is another way of looking at Danny's explanation.

[monsterer]

Halving the difficulty in a hard fork is not a good idea in general, though; that would only be necessary if half of the hash rate was permanently destroyed exactly at the halving time.

If you halve it, without halving the hash rate, network security is halved, since it would only take 25% of the hash rate to perform a 50% attack.

edit: thinking about it some more, all that happens is the block interval shrinks to 5 minutes while the network adjusts, which pays the miners twice as often...

[franky1]

precluse.

i just ran your code. and found something interesting.



the numbers are the same..
http://postimg.org/image/m09ptuovb/

i guess googles 'random' script is broken

[DannyHamilton]

precluse.

i just ran your code. and found something interesting.
- snip -

the numbers are the same..
http://postimg.org/image/m09ptuovb/

i guess googles 'random' script is broken

Nah. It works the way the documentation says it does:

Package rand implements pseudo-random number
- snip -
produces a deterministic sequence of values each time a program is run
- snip -

If you want different results, then either a random enough seed needs to be used to initialize the rand function, or the crypto/rand package needs to be used.

[franky1]

Nah. It works the way the documentation says it does:

Package rand implements pseudo-random number
- snip -
produces a deterministic sequence of values each time a program is run
- snip -

If you want different results, then either a random enough seed needs to be used to initialize the rand function, or the crypto/rand package needs to be used.

its not random.. if i can get the same results as he did .. then there is no randomness to it.
we should never get the same results.

every time you press run should be a different result from the last..

infact out of the 500 results. we shouldnt get even 250 numbers the same, in the exact same place. yet all 500 results are the same every time.

so im gonna try using proper randomness.. not the selective data provided

seems its best to let this topic die because maths, logic and randomness seems to elude people, and im not talking grade school maths either