Hacker News Reader

Comment by nemo1618 | Hacker News Reader

> The PoW is suffice if the hash begins with a certain number of 0s

This is a common explanation of PoW, but is actually incorrect. If you think about it, this would mean that the PoW difficulty could only increase (or decrease) by a factor of two. In reality, the block hash is simply interpreted as a (very large) number, and this number must be less than some other very large number (the "target"). So you do end up with a lot of leading zeros -- but these are just a side effect, not the thing being measured.

View on HN

(author here) Absolutely. Thanks for pointing this out. If difficulty adjusted in factors of two, the ability of the network to accurately maintain its 10 mins blocktime become impaired.

I try to keep these concepts rather simplified to ease the reading and learning process. Perhaps there should be a note for these situations.

In defense of the explanation, sometimes it's asking for an unnecessary mental leap of the reader to think of a bit array as a number, especially if the reader is not accustomed to thinking in base-2 or base-16 number systems.

The hash is just a number regardless-- surely no one has any problem understanding any other number in the protocol as a number! :)

Even this sentence is just a number.

Really it’s not because it’s a sequence of glyphs first and foremost. It can be mapped to a number though.

Nope, no mapping necessary. 36 octets, so a single 288 bit number in base 2. (Big-endian, unsigned, I guess) Then convert to any base you want.

(I should have probably used 32 octets so that it fits neatly in 256 bits)

Isn’t that a mapping? Because the primary purpose of the string of glyphs is readable by humans. Such representation is mapped to the numerical representation for storage in the computer. It may also be mapped to lines of ink written on a piece of paper for transmission

Oh, in my example, it's just a coincidence that the number was readable by humans! Other numbers may come out as complete gibberish.

The "mapping" you may be referring to is happening outside and subject to how your brain /your browser interpret it. (How do you know that when I posted the comment, that I didn't supply the raw bits of the number?! ;-))

Anyway, it was just a joke for low level-programmers I guess. Have a good day ;-)

You could easily explain the basic principles in human-sized numbers (ie, less than 1024).

TIL. I wonder why that myth is so commonly perpetuated.

It used to work this way, but got changed to a less-than check for performance reasons. The Bitcoin whitepaper [0] even has the original approach:

> The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.

[0] https://bitcoin.org/bitcoin.pdf

Gotcha, thanks for the explanation.

> but got changed to a less-than check for performance reasons.

Performance as in "it takes less time to verify the PoW," or something else? Because the "leading zeros" and "less than target" approaches would both take a negligible amount of time.

The story I was told from Bitcoin developers was that it was done for code performance reasons. However, since the less-than check goes back all the way to the code's "Initial commit" [0], I'm not sure if that's fully accurate -- it might have been based on correspondence from the original author. At the very least, the misconception comes from Bitcoin's own whitepaper.

[0] https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...

Weird. That doesn't make any sense to me.

btw, the whitepaper probably used "number of leading zeros" because that's what Hashcash does.

The article mentions the hash is required to begin with a certain number of 0s in hex digits (half byte) whereas the Bitcoin whitepaper refers to it as number of bits. I'm unsure about the comparison (== or >) but the whitepaper seems accurate with regards to the target.

> It used to work this way, but got changed to a less-than check for performance reasons.

I don't know who told you that, but they were weirdly confused.

It not unlikely the case that sometime early in development (long before publication) that it was bits-based, not only is this how the standard hashcash code works-- but the Bitcoin code calls the relevant field that encods the difficulty "bits".

But Bitcoin itself never worked that way, not from the first instant. Changing it would have been a consensus incompatible change, and Bitcoin is still more or less consensus compatible all the way back. (There are outright bugs that make the old software get stuck, but if you fix those, it follows along).

I did not read the sentence you are responding to as implying it was changed after final network launch, only that it was changed.

Well there is no evidence of that other than "bits" and that's how hashcash worked. Sounds like an invitation on the meaning of the word "changed".

No bitcoin software was ever released that worked another way.

I don't know who told you that, but they were weirdly confused.

The bitcoin whitepaper told them that, in more than one place too, so it's not a simple typo, e.g.

...we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.

Bitcoin never worked that way. However the original hashcash proposal was specified as leading zeroes. I presume that’s what you are mixing up with.

There’s a difference between mining bitcoins, and mining for network fees.

What difference would that be? Both the fees and the block reward go to the miner who first published a valid block with hash lower than the current difficulty. The only difference is where those bitcoins came from, but that has no impact on how easy it was to mine.

Yeah as a miner you add the fee and the earned coins to the single coinbase transaction, so it’s a single mining action to get both.

It’s not a myth. It’s a useful simplification.

It's also accurate if you say that hash value H has

-log_2 (H / 2^256) = 256 - log_2 H leading 0s

and allow for fractional number of leading 0s.

The nBits header field closely resembles a 32-bit floating point representation of this number (I say resembles because it's really a floating point representation of the threshold H value).

That doesn't seem like a simplification that misrepresents a relevant, core dynamic of Bitcoin. The exact details of how you ramp up difficulty are a pretty low-level technical issue.

Do you have a source I can look at or do I have to go look at at or can you point to code by chance?

I'm quite surprised I wasn't aware of this if this is actually how it is implemented, the leading zeroes seemed right (and the difficulty by factor of 2 also!)

Thanks!

Someone else linked it below: https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...

Equivalent check in btcd, an alternative Bitcoin implementation: https://github.com/btcsuite/btcd/blob/991d32e72fe84d5fbf9c47...

How is network consensus achieved on the difficulty adjustment?

Each node independently comes to the new difficulty on their own in an entirely deterministic way.

After 2 weeks there should be 2016 blocks mined, 1 block every 10 minutes. After each 2 week period every node recalculates the new difficulty based on the actual number of blocks mined in the last 2 weeks. If the actual number of blocks produced was 25% higher than the target of 2016, then simply increase the difficulty by 25%.

Thanks. Given that this relies on subjective timestamps, is this really entirely deterministic? I can imagine that one node counted 2014 blocks in the past two weeks, another 2015. What happens in such cases?

Difficulty only changes at heights that are a multiple of 2016.

It is computed using only information embedded in the block chain, specifically the timestamps of blocks 2016 * i and 2016 * (i+1).

But aren't blockchain timestamps unreliable? It was my understanding that difficulty was based on subjective node timestamps..

The miner embeds their current (local) timestamp in the header, so there can be small variations. In fact the only requirement on the next timestamp is that it not be less than the median of the past 11 timestamps.

Once embedded in the header, everyone will agree on past timestamps as they agree on the chain with the most accumulated difficulty.

Reply on news.ycombinator.com