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

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