Hacker News Reader

This is not true - the probability of mining a block in the future is relative to the time spent mining (a Binomial).

The probability of finding a block does not change based on how long someone already has been mining.

Consider a fair coin - even if you get tails 20 times in a row, the probability of getting heads on the 21st try is still 50%.

In contrast, the probability of getting a heads at least once in 20 tries is 1-1/2^20.

The crucial point which you omitted is that the hash output is uniformly random.

Yes - to be precise approximately 1/(2^32*difficulty) chance any one hash is a block solution.

You're being downvoted for some reason, but you are right. This is a variation of the Gambler's fallacy, where the miner thinks that because it has mined on branch 0 for some time, the expected time to mine a block on branch 0 in the future will be shorter than on branch 0'.

By way of directly illustrating this, consider slot machines with identical payouts. Grandma has been inserting coins into slot machine A for twenty minutes, when suddenly slot machine A' is turned on. There's no difference between continuing to pump coins into slot machine A and switching slot machine A', the expected payoff is the same either way.

This is mostly true. Sometimes it's worth it to continue playing on the original slot machine if it has some sort of progressive feature like a jackpot that isn't shared with other machines of the same type.

The argument depends crucially on how the hash space is searched. If you could avoid inputs that yield previously seen hash outputs then it would be the case that time previously spent mining would decrease the expected time until getting a valid hash. That doesn't happen by design.

Analogies to slot machines and flipping coins obscures this fact.

How would one productively store previously seen hash outputs? The problem is multi-fold:

Storing the minimum target nonce seen during mining has a key-space of size 256+96=352bits { midstate + { merkle_root, ntime, nbits } }.

So 1/2^352 chance of ever having a collision. Or 2.725094297605216460742E-107. 107 zeros between the decimal and the first interesting digit.

However you wouldn't have indexed this because ntime (the current time) is always going to be unique, and nbits (the current difficulty) might as well be too.

A single bit change in any part of the key completely changes the result, so there is no pattern you can infer by only storing a prefix.

Such a strategy is doomed.

EDIT: ntime is effectively unique as it is the Unix time and will roll over after many years, but the Bitcoin network requires mined blocks to have an ntime within threshold of the current actual time.

> How would one productively store previously seen hash outputs?

You can't, that's why your argument works here. It wouldn't work on a system where the objective was to find a secret number in 1 to N.

> Suppose there are two branches, 0 and 0'. Miner receives 0 first. The probability of mining a block is proportional to the time spent mining. Miner thus (a) starts mining 0 immediately upon notification and (b) has a greater probability of finding a block on 0 than 0'.

Your mistake is in the last point. The probability of finding a block in the next X time units is completely independent of what you did in the past (unless you managed to break the underlying cryptographic hash somehow ;-)). You can think of mining as repeated coin throws (with an extremely biased coin).

This is spot on, no one would actually follow that protocol.

Tangentially, the best side effect of HFT seems to be that a lot of technical people have become more sophisticated in understanding incentive structures and contracts. I wonder how that affects funding decisions for startups of the ex-HFT crowd.