Luke Jr's HARDFORK proposal debunked

[franky1]

firstly lets get the fundementals out of the way.

luke Jr wants to do a hard fork to drop the difficulty because he WRONGLY thinks blocks will take longer to mine due to events of the reward halving.

now to understand this you need to know some basics that luke jr has not factored in.

when a pool solves their block. the solution is based on the work done by just that pool. not the entire network.

its the data processed within that pool that keeps attempting different combinations until it finds a solution.
any 'work' done by pool B is not shared with pool A.. they are separate pools and their attempts are not related in any way.
the work is independant to the individual pool. and not shared. only the end solution is shared.. not the work

so say pool A solves a block in 10 minutes.
if pool B decided to give up and claim bankruptcy. it would not affect pool A's work at all, pool A would still have solved that block in 10 minutes.

also
block difficulty is not based on network hashrate. but based on the times of each block solved over  2016 blocks.. if its less than 2 weeks the difficulty changes.

so say pool A solved 2016 blocks in a row. it does not matter what the hash power of pool B, C, D, E is. because they have not solved any blocks.
also its not a guarantee that the pool with the top hashpower is going to solve every block. so again hashrate is not important.

now lets get into understanding the scenario
when 1 pools solves a block the other pools dump the attempts and move onto the next one(usually).

now in a nice world of statistics we would love it if when a block is solved the other pools continue on until they too have a solution. and then publicise the average time it takes for each pool to make a block.. rather then just knowing fastest first.(basically having 20 time statistics for each of the 20 main pools, instead of 1)

so my scenario is based on a random number of between 8 minutes to 40 minutes to represent the average times a miner would solve a block.
below is a table that has marked in green the 'fastest first' winner. but also has the average(random) times which the other pools would get a solution if they didnt ditch their attempts.

the reason for including the times is so that if we start to remove certain pools from the table we can see who would be next in line to win in a scenario where some of the pools didnt mine.. all times in the cells are random numbers between 8minutes to 40 minutes.. you too can easily try this yourself
i originally thought about doing 5-20 minutes randomness for the top 6 pools and 8-40 minutes for the remaining 14, to closer resemble pool hashpower percentages
 but instead thought 8-40 for all 20 pools would be fairer and less chance of knitpickers moaning.. because the numbers are larger and more fair to the naysayers



so above shows a healthy amount of pools making blocks 8-12 minutes.

now lets take away the pools that solve blocks often. lets pretend that these are the massive mining farms that luke jr presumes will go bankrupt due to the reward halving.

infact there were 20 pools listed. so lets take away the top 10 pools.. because luke Jr's presumption is that pools would take atleast 20 minutes to solve..if 50% was lost.... so lets lose the top 50% as the extreme scenario.. and see how it plays out



now.. this if luke Jr was right would show no miner making a block in less time then 16 minutes.. yet the table still shows 8-12 minutes.. so luke is wrong

now lets instead of thinking that its the top 10 pools that will go bankrupt.. but instead its the smaller pools that dont have a chance of solving as often even before the halving.



so in both scenarios blocks are still being made in 8-12 minutes.

now i want you to try it yourself.. and no before you even think about it, dont put in fake numbers to try to make a fake rebuttle example, be honest to yourself. so that you can see for yourself..
the formula i used is
=RANDBETWEEN(8,40)&":"&RANDBETWEEN(10,59)

8,40 is the number of minutes 8 to 40
10,59 is the number of seconds 10 to 59.  i done 10 instead of 1 purely for visual aesthetics because single digits look uglier. but you are free to do 1-59 as it makes no difference.

have fun making your own scenarios. and if you are going to be a twog and manually type in data just to fake a rebuttle. your only ultimately lying to yourself. so use honest random formula not manual numbers.

and you will hopefully come to the same conclusion i have.. that if pools drop out due to less rewards, it wont cause longer block solvings. because as i said if pool B drops out it wont affect pool A's work in any way

[1714984492]

1714984492

[1714984492]

1714984492

[j.faber]

TL;DR:

=RANDBETWEEN(8,40)&":"&RANDBETWEEN(10,59)

so in both scenarios blocks are still being made in 8-12 minutes.

i done 10 instead of 1 purely for visual aesthetics because single digits look uglier.

[imagine the biggest possible facepalm GIF here]

[franky1]

TL;DR:

=RANDBETWEEN(8,40)&":"&RANDBETWEEN(10,59)

so in both scenarios blocks are still being made in 8-12 minutes.

i done 10 instead of 1 purely for visual aesthetics because single digits look uglier.

[imagine the biggest possible facepalm GIF here]

=RANDBETWEEN(minutes)&":"&RANDBETWEEN(seconds)
does not limit the results to be forced between 8-12 or sways them into that direction either..  they are 2 sets of randomness one for minutes one for seconds.. the former is not limiting or manipulating the latter.

my formulae was formatted that way for visual purposes of doing a screenshot where the random minutes and seconds are still random. but presentable in the MM:SS format

but fill free to use
=RANDBETWEEN(480,2400)
480=8 minutes
2400=40 minutes

and then notice there still a pattern of between 480 and 720 average (8-12minutes)

[j.faber]

That's all irrelevant. You are misleading yourself in your 2nd sentence:

when a pool solves their block. the solution is based on the work done by just that pool. not the entire network.

That's true. Now answer these two:

1) So with 20 (equal size) pools, how long does each pool (on average) take to mine one block? Answer: 10 * 20 = one block every 200 minutes.

2) Then 10 pools shut down, same question: How long does each pool (on average) take to mine one block?

Remember that you just said that the pool doesn't care about how much work the rest of the network does.

but presentable in the MM:SS format

That's what number formats are for.

[franky1]

That's all irrelevant. You are misleading yourself in your 2nd sentence:

when a pool solves their block. the solution is based on the work done by just that pool. not the entire network.

That's true. Now answer these two:

1) So with 20 (equal size) pools, how long does each pool (on average) take to mine one block? Answer: 10 * 20 = one block every 200 minutes.

2) Then 10 pools shut down, same question: How long does each pool (on average) take to mine one block?

Remember that you just said that the pool doesn't care about how much work the rest of the network does.

but presentable in the MM:SS format

That's what number formats are for.

it does not take a pool 200 minutes to solve a block.. wake up will you.
if each pool took 200 minutes then each block would be 200 minutes!

lets say pools make a block on average between 8-40 minutes. but out of 20 pools one of those is going to be lucky to get a solution faster then the rest.. which is the point of the table (average 10 minutes fastest solution)
say we have 3 pools
R    8:41
G    9:50
M  10:45

when R finds a block. usually G and M stop working dispose of their attempt and reset the counter to zero..
and starts on a new block. the counter WONT continue on until they get a solution before anyone else, because that block data is solved and dealt with.
its lost time.
from the network and code point of view a block is solved in an average of 10 minutes.. the time between when a pool gets paid is irrelevant.
again a block wont take 200 minutes to solve. a block on average takes 10 minutes,

i really wonder, where out of the darkest recesses of a black hole did you ever assume that it takes 200 minutes to make a block??

seriously..
all pools take 8-40 on average. but if 1 pool is lucky to solve first. the other pools give up
that means the timer is reset to zero when they start a new block.
the timer does not continue until 20 blocks are found.

if you think that the 20th pool has been working on only 1 block the whole time the other pools were working on the other 19 blocks.. then you have missed the fundamentals of mining

just because they 20th pool only got paid once in 20 blocks does not mean it has only been working on one block for the whole time

[achow101]

Your fundamental assumptions are wrong.

First of all there is empirical evidence which directly relates the network hashrate to the difficulty. As the hashrate has increased so has the difficulty and vice versa.

Secondly, you have the wrong assumption that blocks will be found by a single pool every ten minutes on average. That is the wrong assumption.

There are 2^256 - 1 possible solutions. A pool will only  search through 2^64 hashes for each set of transactions that it includes in a block. Note that each pool will have a different transaction set due to choosing different transaction and setting different coinbase script text.

For the sake of simplicity let's assume that each pool has the same hashrate and that there are 10 pools (pools can also be interchanged with individual miners). In, say, 1 hashes, 10*2^64 hashes will be searched, way short of the 2^256 - 1 possible hashes. After 10 minutes, 100*2*64 hashes will be searched. With whatever difficulty is set, within that set of hashes, there will be at least 1 block solution (actually there will probably 1 solution).

Now if there are suddenly 5 pools but the difficulty stays the same, 100*2^64 hashes will need to be searched but only 50*2^64 hashes will be searched. That means there are 50*2^64 hashes that haven't be searched yet. In order to have a high probability of having found the block, each pool will have to search another (1/5)*2^64 hashes which will take an extra (1/5)*(10-5)=10 minutes to search the remaining space to find the block.

tl;dr you are assuming that pools are searching from the same place, but they don't and all start and search different areas of the hash space.

[DannyHamilton]

just because they 20th pool only got paid once in 20 blocks does not mean it has only been working on one block for the whole time

Actually, that's exactly what it means.

There is no "giving up".

Pools continuously calculate hashes until they find a valid solution, then they go back to continuously calculating hashes until they find a valid solution again.  There is never any progress towards a solution for any pool, or for the network at all.  Every hash has an equal chance of being a valid solution regardless of whether it is the first attempt or the 100 billionth attempt.

[franky1]

just because they 20th pool only got paid once in 20 blocks does not mean it has only been working on one block for the whole time

Actually, that's exactly what it means.

There is no "giving up".

Pools continuously calculate hashes until they find a valid solution, then they go back to continuously calculating hashes until they find a valid solution again.  There is never any progress towards a solution for any pool, or for the network at all.  Every hash has an equal chance of being a valid solution regardless of whether it is the first attempt or the 100 billionth attempt.

the hash is data+nonce
where the data is specific to that individual block.. miners do not use the same data for 200minutes.. as soon as they see someone else has a solution(in the 10 minute average). they dump that data and start afresh on the next block. as there is no point mining a block thats already solved by someone else.

miners do not endlessly work on one set of data for 200 minutes.

[DannyHamilton]

the hash is data+nonce

Correct.  The hash is calculated using a block header as the input to the hash where the block header consists of:

• Version
• Hash of the previous block
• Merkle root
• Timestamp
• Difficulty target
• Nonce

miners do not use the same data for 200minutes..

The amount of time that a miner spends on a specific block header depends on their hash rate.

There are 4294967296 possible nonce values in the block header.  Antpool has a hash rate of 271.70 petahash/sec.  At that rate, they "use the same data" for about 0.000000015 seconds before they give up and move on to a new block.

as soon as they see someone else has a solution(in the 10 minute average). they dump that data and start afresh on the next block.

Also, as soon as they've exhausted the nonce range, they dump that data and start afresh on a new block.  Most of the larger pools attempt to solve millions of different blocks per second.

as there is no point mining a block thats already solved by someone else.

There's also no point mining a block that you've already determined has no solution.

miners do not endlessly work on one set of data for 200 minutes.

Nope.  They endlessly work on billions of sets of data for 200 minutes, throwing away all the unsolvable blocks until 200 minutes later they've finally found (and solved) a solvable block.

[franky1]

ok lets translate this into english

the data containing the hash of the previous block... and the ultimate solution of the new solved block that appends on after the previous hash is an average of 10 minutes. NOT 200 minutes.
EG block 425,000 contains the blockhash of 424,999 so the timer begins between when 424,999 was solved and when 425,000 is solved.
not 20 blocks ago. not 425000 blocks ago. just the time between one block and the next

now have a sit down. a cup of coffee.. maybe even have a biscuit and relax your mind. clear any thoughts about how often a miner gets paid. and instead think about the time between when a miner uses data of block 424,999 to start working on a solution for block 425,000

now with that mindset. look at my original post.

and again the average time it takes a miner to have previous block hash of 424,999 and combine it with the other data, and hash it away until they find a solution for 425,000 is an average of 8-12 minutes going by my random numbers.

now using the first table in the OP. even if A,F,I,M,N,O,R,S it would not bring the average to 16-24 minutes. because the although R no longer available to solve block 425,000.. G would have came up with the solution just 1minute 9 seconds later.

try to separate the mindset of how often a miner gets paid, and concentrate on the times of a solution that include the data of the previous hash, you know the time scale of 1 blocktime.

EG if i asked you to tell me the fastest time that block 425,011 was solved from the time it started hashing away data that included 425,010 previous block. you would tell me 10:44, made by pool P.

would you seriously reply to say that it must be 116 minutes and 30 seconds because pool P didnt solve a block from 425,000 to 425,010 so the timer must start from 425,000? i hope not

now if i told you to take away pool P and pretend it did not exist before even making the block.
also take away B,C,D,E,G,H,J,K,T (look at table 3 in the OP)
so now there is only 50% of pools left.

would you seriously tell me it would take another pool to start hashing block 425011, containing data of block425010.. atleast 21 minutes 28 seconds (double the other pool as luke JR suggests)?
would you seriously tell me it would take another pool to start hashing block 425011, containing data of block425010.. 200 minutes

by looking at the third table you would see that pool O got the solution if pool P didnt exist.
so will you tell me it took 33minutes 27 seconds because your counting the time from the last time that particular pool got paid
so will you tell me it took 200 minutes because somehow the number of pools has relevance to the randomness of nonce. within the work of just that one pool
no. because pool O got a solution in 11 minutes 4

remember the average time to make a block is not based on how often a particular miner gets paid
a block is the 10 minute average from when it starts handling the blockhash of the previous block until its got the fastest solution compared to competitors.
then the time is reset, as a clean slate.

i have no clue what black hole some of you have jumped into to think each block takes 200 minutes each.
the difficulty is based on 2016 blocks, each found at 600 seconds. (1209600 total seconds before difficulty adjustment).
the difficulty adjustment does not care who solved the blocks or how many times a particular pool solved blocks. it just cares about the 1209600 seconds to make 2016 blocks. and adjusts +/- depending if its faster or slower

because the difficulty does not care who got paid multiple times or who got paid only once a fortnight.. its not about payments. its about how long it takes for a pool to hash out a solution to a block that includes data of the last block.

the ultimate funny part is that if luke JR thinks a hardfork code can be implemented in april to be active for july THIS YEAR.. is acceptable.. then his own acceptance of a short grace period debunks the need for 16months of delay for the 2mb hard fork

[j.faber]

luke Jr .... because he WRONGLY thinks

it does not take a pool 200 minutes to solve a block.. wake up will you.
if each pool took 200 minutes then each block would be 200 minutes!

Dude! Just fuck off for a year and learn how Bitcoin works! You're insulting a Core dev that runs his own pool, and you clearly don't know *anything* about Bitcoin.

the ultimate funny part is that if luke JR thinks ...

Also, the fact that you're saying this shit about Luke with your proven level of understanding, makes it blatantly obvious that you're hanging around with the wrong crowd (let me spell that out for you: classic). Leave there, they're messing with your brain. Spend that year truly learning Bitcoin.

[franky1]

luke Jr .... because he WRONGLY thinks

it does not take a pool 200 minutes to solve a block.. wake up will you.
if each pool took 200 minutes then each block would be 200 minutes!

Dude! Just fuck off for a year and learn how Bitcoin works! You're insulting a Core dev that runs his own pool, and you clearly don't know *anything* about Bitcoin.

the ultimate funny part is that if luke JR thinks ...

Also, the fact that you're saying this shit about Luke with your proven level of understanding, makes it blatantly obvious that you're hanging around with the wrong crowd (let me spell that out for you: classic). Leave there, they're messing with your brain. Spend that year truly learning Bitcoin.

the only reason luke JR wants a difficulty decrease is for his own selfishness and greed to let his own pool survive a couple months longer due to it being unable to compete against the big guys.
its not about the pools as a whole entire community. its not even about a fix that would last more then a month.

and everyone know that it does not take 200 minutes to make a block. (when miners are hashing blocl 425000 they are not using data(transactions) from block 424980(200 minutes ago)

im not a classic fanboy. i am not in any camp. i also have no allegiances to anyone so if anyone has spouted out wrong info i have no problem being frank about it.

but i do love how people protect friends before thinking about the code and community as a whole. and your only rebuttle is not a evidence based or a factual filled rebuttle, but an insulting ramble.

i dare you to prove that miners making a current block are hashing out data from blocks 20 blocks ago (200minutes). if you cant supply the proof dont reply. and let this topic die (easy solution to your problem)

[Preclus]

franky's comment is:

"luke Jr wants to do a hard fork to drop the difficulty because he WRONGLY thinks blocks will take longer to mine due to events of the reward halving."

which I would assume is in reference to lukejr's comment here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

where he states:

"For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average and contain double the transactions they presently do."

Solving blocks is a game of chance. The network attempts to adjust difficultly so blocks can be solved in a certain amount of time (10 minutes). However, blocks can be solved earlier or later than the 10 minute target since it is a game of chance. A miner runs through nonces and other things making different blocks trying to find one with a hash value that has a certain number of leading zeros. You are trying to find one before everyone else does.

The process it the same as players throwing dice and trying to get a certain number first. So, let's look at that game of chance instead of block solving.

Consider 20 players in a game trying to throwing single dice where they keep throwing dice until they get a 6. When one gets a 6, he wins and can publish his win and everyone starts over. Let's assume that it takes 5 seconds for a player to throw their die and see the result.

What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^20) = ~97%

Now, let's say we lose half the players. What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^10) = ~84%

As we get fewer players, it will take longer, on average for a player to roll a 6 in a given amount of time.

However, halving the number of players does not double the amount of time it takes to roll a 6 on average when you have a reasonable number of players.

Luke's post is incorrect in stating that blocks would take double the time, 20 minutes on average, to solve if 50% of the miners dropped off the network immediately.

It is true that miners dropping off the network does increase the time, on average, it takes to solve blocks without any change in difficultly. But with a reasonable number of miners and assuming the 50% of miners who may drop out isn't just the group of fastest miners, even half the miners dropping out would not change the time it takes to solve blocks in any dramatic way.

[cr1776]

...
What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^20) = ~97%

Now, let's say we lose half the players. What are the odds a player will get a 6 in the first 5 seconds (first roll)?

1 - ((5/6)^10) = ~84%
...

It is true that miners dropping off the network does increase the time, on average, it takes to solve blocks without any change in difficultly. But with a reasonable number of miners and assuming the 50% of miners who may drop out isn't just the group of fastest miners, even half the miners dropping out would not change the time it takes to solve blocks in any dramatic way.

Luke Jr is talking about half the hash rate dropping off the network, not necessarily half the miners.  Regarding the statistics that is right for the first roll when you have more players than numbers, but we're not talking one roll in a certain period of time with a small search space.  E.g. we don't have more players than search space.

If you have a 1000 sided die, and 10 players, look at the stats for that to roll a 1 on the first try?  1/100
If you have a 1000 sided die, and 5 players, look at the stats for that to roll a 1 on the first try? 1/200
Then calculate the expected number of rolls until you get a 1 for each.  The impact of cutting the number of players/hash rate in half should be obvious.


You should review what knightdk says:

Your fundamental assumptions are wrong.

First of all there is empirical evidence which directly relates the network hashrate to the difficulty. As the hashrate has increased so has the difficulty and vice versa.

Secondly, you have the wrong assumption that blocks will be found by a single pool every ten minutes on average. That is the wrong assumption.

There are 2^256 - 1 possible solutions. A pool will only  search through 2^64 hashes for each set of transactions that it includes in a block. Note that each pool will have a different transaction set due to choosing different transaction and setting different coinbase script text.

For the sake of simplicity let's assume that each pool has the same hashrate and that there are 10 pools (pools can also be interchanged with individual miners). In, say, 1 hashes, 10*2^64 hashes will be searched, way short of the 2^256 - 1 possible hashes. After 10 minutes, 100*2*64 hashes will be searched. With whatever difficulty is set, within that set of hashes, there will be at least 1 block solution (actually there will probably 1 solution).

Now if there are suddenly 5 pools but the difficulty stays the same, 100*2^64 hashes will need to be searched but only 50*2^64 hashes will be searched. That means there are 50*2^64 hashes that haven't be searched yet. In order to have a high probability of having found the block, each pool will have to search another (1/5)*2^64 hashes which will take an extra (1/5)*(10-5)=10 minutes to search the remaining space to find the block.

tl;dr you are assuming that pools are searching from the same place, but they don't and all start and search different areas of the hash space.

[franky1]

the maths of lukes proposal doesnt work because pools compete with each other, they dont combine hashes and work together. they dont decide BTCC is to solve nonce 0-1,000,000 antpool to solve 1,000,001-2,000,000, and so on.

now then, i have had time to contemplate where people are getting this 200 minute theory
now here goes.

if there were 20 pools with equal hash. then the difficulty would need to be so high that only 1 averages a block every 10 minutes.

translated.
if there was a 200 sided dice(possible combinations) then if one person rolled it 1 time a second. it would take them 200 seconds to roll the lot.
now with 20 people each rolling once a second at the same time.. the odds are that one person would get a particular magic number in 10 seconds
now when that winner gets the special number. the other 19 people do not keep rolling for another 190 seconds. they call it round1 win, second round begins. and everyone starts with the counter at 0

so using the 20 bitcoin pools of equal hashrate, where there are 200 minutes worth of combinations. the average block is solved in 10 minutes. and we never see all 19 other pools continue hashing the same data for the other 190 minutes. they stop what they are doing and immediately work on the next blockheight. and the counter begins again at 0

now thats been dealt with.
lets say (table 1 of my OP) block 425000

R was lucky in 8 minutes 41 seconds.. does that force G to only be lucky in 17minutes 22seconds? no
G can have any luck between 2-200minutes, infact his luck came in at 9:50
does G's luck impact M's luck making M some how slower and take 19:40..... again no
M can have any luck between 2-200minutes, infact his luck came in at 10:45

so if we took out 10 of the top performing pools (table B)
would the luck be 20 minutes.. nope 9:50. because pool G before never solved a block he always lost the competition. but now he is lucky getting many blocks because there is less competition and in block 425000 he didnt have to lose against R because R doesnt exist

i would have however gone with lukes proposal if he worded it more honestly
'the reward halving is a reduction in income. so lets unnaturally halve the difficulty to double the income (blocks average 5 minutes for 2 weeks) thus not impacting miners profits. and then let the natural difficulty adjustments increase by 10% every 2 weeks. giving pools a delayed and slower reduction of income over 10 weeks, instead of an instant drop overnight'

that to me is atleast the honest result of what luke wants. without baffling people with fake maths

[Preclus]

Luke Jr is talking about half the hash rate dropping off the network, not necessarily half the miners.

Luke Jr stated: "For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average...". The link to his statement online is my previous post above.

If you have a 1000 sided die, and 10 players, look at the stats for that to roll a 1 on the first try?  1/100

If you have a 1000 sided die and 10 players, the odds of (at least) one rolling a 1 on the first try is:

1 - ((999/1000)^10) = ~0.9955%

it is not 1/100 which is equal to 1%.

Consider you had a 3 sided die and 2 players, what are the odds that at least one throws a 1 on the first try? The answer is: 1 - ((2/3)^2)

To understand this, let's look at the possible combinations:

[player 1's throw, player 2's throw]

[1, 1] [1, 2] [1, 3] [2, 1] [2, 2] [2, 3] [3, 1] [3, 2] [3, 3]

in 5 cases, at least one of the players threw a 1. There are 9 possible combinations of results. So, there is a 5/9 chance of a player throwing a 1 on the first throw which is not 2/3 (that would be 4/9) and 1 - ((2/3)^2) = 5/9

[cr1776]

As far as what Luke said, I know what he said and had seen it previously, but it seems clear his meaning was half the hash rate, not half the miners since that metric is meaningless.  "Half the miners" might control 1% of the hash power or 90% depending on who is included in the 50%group. He wasn't be precise, but thought most people would understand his meaning.

I was just giving approximate numbers which given the immense search space involved become even closer to the approximation.  For all intents and purposes the 0.005% difference is meaningless in these numbers and is much smaller in reality so approximations are fine:
E.g. A 2^64 or 2^256 sided die even with 10000 miners/players doing a single roll.  Even if there were 1 million miners doing a single roll, it wouldn't change the math significantly.

Try taking your dice the other way, instead of making them smaller, make them much, much, much, much larger and hopefully you will understand where the error is.

Luke Jr is talking about half the hash rate dropping off the network, not necessarily half the miners.

Luke Jr stated: "For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average...". The link to his statement online is my previous post above.

If you have a 1000 sided die, and 10 players, look at the stats for that to roll a 1 on the first try?  1/100

If you have a 1000 sided die and 10 players, the odds of one rolling a 1 on the first try is:

1 - ((999/1000)^10) = ~0.9955%

it is not 1/100 which is equal to 1%.

Consider you had a 3 sided die and 2 players, what are the odds that at least one throws a 1 on the first try? The answer is:

1 - ((2/3)^2)

To understand this, let's look at the possible combinations:

[player 1's throw, player 2's throw]

[1, 1] [1, 2] [1, 3] [2, 1] [2, 2] [2, 3] [3, 1] [3, 2] [3, 3]

in 5 cases, at least one of the players threw a 1. There are 9 possible combinations of results.

So, there is a 5/9 chance of a player throwing a 1 on the first throw which is not 2/3 (that would be 4/9) and

1 - ((2/3)^2) = 5/9

[Preclus]

As far as what Luke said, I know what he said and had seen it previously, but it seems clear his meaning was half the hash rate, not half the miners since that metric is meaningless.  "Half the miners" might control 1% of the hash power or 90% depending on who is included in the 50%group. He wasn't be precise, but thought most people would understand his meaning.

Yes, it is important which miners drop out, that is why I stated:

"But with a reasonable number of miners and assuming the 50% of miners who may drop out isn't just the group of fastest miners, even half the miners dropping out would not change the time it takes to solve blocks in any dramatic way."

Even if you are talking about losing 50% of the hash rate, the math still doesn't work. You can't say you lose half the hash rate and that causes the time it takes to solve blocks to double. The impact depends on the distribution of miners, the rate at which they can solve blocks individually and which one of them would drop out. Nothing that I wrote was in error.

The original post in this thread was reasonable enough (though light on hard math ) and gave more real world example numbers.

In terms of franky's reworded proposal (not his proposal, I know):

the reward halving is a reduction in income. so lets unnaturally halve the difficulty to double the income (blocks average 5 minutes for 2 weeks) thus not impacting miners profits. and then let the natural difficulty adjustments increase by 10% every 2 weeks. giving pools a delayed and slower reduction of income over 10 weeks, instead of an instant drop overnight

That is a much better way of explaining things. That proposal would increase miner payouts at a very fundamental level during reward halving. Any  increase in miner rewards is born by users in the end and if they are willing to increase miner payouts during that point in time, then it would seem that increasing mining payouts could be considered whenever there was a perceived issue that might impact miner profits. And if that is true, continuing to halve rewards or even holding to a 21MM cap would seem questionable if the thought is that the system can't support itself on transaction fees alone.

[DannyHamilton]

I realize that probability, combinations, permutations, and poisson distributions can be confusing concepts to grasp and understand, but there is a lot of very bad (in other words, incorrect) math in this thread.

I'll try to work out a realistic analogy...

Here's the set-up:

• 20 players in my mining game
• Each rolls a set of four six-sided dice once per second for their mining process in my game
• If any player gets 1 on all four dice, they "win" that block, and we start the game again
• We create a score sheet that indicates which round of the game we are on, and when someone wins a round, we write their name on the score sheet next to that round number
• A referee watches the game with a stopwatch and writes down the amount of time between rounds

So, the score sheet is our "blockchain", the round number is our "previous hash", the dice are our nonce/hash, the four 1's are the "difficulty", and the players are our "miners".

Question 1: On average how long does it take for someone to "win" a round?
Answer 1:  64.8 seconds
Reason: It takes (on average) 1296 random rolls of four dice to get 1 on all four dice simultaneously.  The dice don't remember what has happened in the past, and they don't know what the other dice are doing.  Therefore, it doesn't matter if those 1296 random rolls are separated by minutes, or nanoseconds, it still takes an average of 1296 rolls.  Since there are 20 people rolling every second, it will take an average of 1296 / 20 = 64.8 seconds until someone shows 1 on all four dice simultaneously.

10 people decide that they don't want to play the game anymore and they leave.

Question 2: On average how long does it now take for someone to "win" a round?
Answer 2: 129.6 seconds
Reason: It takes (on average) 1296 random rolls of four dice to get 1 on all four dice simultaneously.  The dice don't remember what has happened in the past, and they don't know what the other dice are doing.  Therefore, it doesn't matter if those 1296 random rolls are separated by minutes, or nanoseconds, it still takes an average of 1296 rolls.  Since there are 10 people rolling every second, it will take an average of 1296 / 10 = 129.6 seconds until someone shows 1 on all four dice simultaneously.

Clearly, both when there are 10 players and when there are 20 players, there will be times when someone gets lucky and "wins" on the first roll of the round (meaning that round only takes 1 second).  There will also be times when nobody gets lucky and it takes more than triple the average time until the four 1's show up. But if the game is played long enough and you average all the round times, you'll find that the AVERAGE is as stated.

Two of the biggest problems with the spreadsheet in the OP are:

• It assumes that every possibility of duration between 8:10 and 40:59 are equally likely for every miner.
• It completely ignores the extreme results (those times when several blocks can occur in the same minute, and when hours occur between blocks)

By using only times that actually fall near the average, it creates a false sense that removing participants leaves the results still near the average.

[Preclus]

I realize that probability, combinations, permutations, and poisson distributions can be confusing concepts to grasp and understand, but there is a lot of very bad (in other words, incorrect) math in this thread.

That was a very well written and clear post. Your math is correct and my previous conclusion was wrong.

[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

[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