5 ms·

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

Jasper_ 6y ago
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 https://bitcoin.org/bitcoin.pdf
- sodascripts 6y ago
  Gotcha, thanks for the explanation.
- nemo1618 6y ago
  > 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.
  - Jasper_ 6y ago
    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/e071a3f6c06f41068ad17134189a4ac3073ef76b/main.cpp#L1179-L1181 https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...
    - nemo1618 6y ago
      Weird. That doesn't make any sense to me. btw, the whitepaper probably used "number of leading zeros" because that's what Hashcash does.
    - monokh 6y ago
      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.
- nullc 6y ago
  > 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).
  - saurik 6y ago
    I did not read the sentence you are responding to as implying it was changed after final network launch, only that it was changed.
    - nullc 6y ago
      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.
  - joosters 6y ago
    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.
- garmaine 6y ago
  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.
- jbverschoor 6y ago
  There’s a difference between mining bitcoins, and mining for network fees.
  - trickstra 6y ago
    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.
    - exdsq 6y ago
      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.
runeks 6y ago
It’s not a myth. It’s a useful simplification.
- tromp 6y ago
  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).

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 https://bitcoin.org/bitcoin.pdf

sodascripts 6y ago
Gotcha, thanks for the explanation.
nemo1618 6y ago
> 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.
- Jasper_ 6y ago
  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/e071a3f6c06f41068ad17134189a4ac3073ef76b/main.cpp#L1179-L1181 https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...
  - nemo1618 6y ago
    Weird. That doesn't make any sense to me. btw, the whitepaper probably used "number of leading zeros" because that's what Hashcash does.
  - monokh 6y ago
    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.
nullc 6y ago
> 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).
- saurik 6y ago
  I did not read the sentence you are responding to as implying it was changed after final network launch, only that it was changed.
  - nullc 6y ago
    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.
- joosters 6y ago
  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.
garmaine 6y ago
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.
jbverschoor 6y ago
There’s a difference between mining bitcoins, and mining for network fees.
- trickstra 6y ago
  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.
  - exdsq 6y ago
    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.

runeks 6y ago

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

tromp 6y ago
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).