Topic: Luke Jr's HARDFORK proposal debunked (Read 2524 times)

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

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


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.

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

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

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.

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.

Correct.


Yes, it is.


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.


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.


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.


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.


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


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.


And others have taken more than an hour.


Correct.


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.


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


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.


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.



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


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.

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

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.

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


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.

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.

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

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

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.

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.

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

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

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:

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.