5 ms·
One minor error, but the implementation of difficulty in proof-of-work is not based on the number of leading zeroes, rather whether an integer is below or above
by liamzebedee 11y ago
One minor error, but the implementation of difficulty in proof-of-work is not based on the number of leading zeroes, rather whether an integer is below or above a target.
- lisper 11y agoThose are the same thing when the target is a power of 2.
- misterdata 11y agoThe number of leading zeroes as read in binary notation, that is.
- deleted 11y ago[deleted]
- vog 11y agoSure, but the PoW mechanism is more fine grained, and I think it is important to point that out. Otherwise, people might indeed think that the difficulty will always be a power of 2, which would mean that adjusting it would have been harder (and more inaccurate) than it really is.
- lisper 11y agoI dunno, that seems like a pretty small nit to me. But I suppose reasonable people could disagree.
- arcatek 11y agoI've worked on a coin, and this kind of inexactitude are what make it really hard to understand how the implementation works (that, and the fact that the code was hell at the beginning). If the code uses a "less-than" operator, just tell it. It makes no sense to use a different terminology (in this particular case, the "number of leading zero" concept was probably used to make it easier to understand for business guys - it doesn't work quite well).
- vog 11y agoMoreover, I believe that talking about plain numbers and "less-than" actually makes explaination easier, compared to talking about strings and leading zeros. Using plain numbers, I would explain it to a layperson like this: The hash is number from 1 to 1,000,000 (actually, it's a lot larger and we are counting from zero, but you get the idea). You can't control how large or small the value is. If some people generate a hash of 10,000 or below, this means they had to try roughly 100 times, computing 100 hashes, until they found that one by chance. This is a "Proof of work". If you reduce the threshold from 10,000 to 5,000, people will have to compute on average 200 instead of 100 hashes. So the smaller the threshold, the more difficult the challenge is to solve. On top of its simplicity, this explaination has the advantage that the statistics are pretty obvious and don't even contain exponentials or logarithms, which you would have to use when talking about strings and leading zeros.
- xxs 11y agoYou can't control how large or small the value is. If some people generate a hash of 10,000 or below, this means they had to try roughly 100 times, computing 100 hashes, until they found that one by chance. Not to be blunt, yet after 100 attempts w/ 1% positive outcome, there is roughly 63.3% odds to actually succeed.
- tromp 11y agoThe expected number of trials, each with 1% of success, is 100 though.
- mikeash 11y agoThat's probably why the comment above that pointed it out called it a "minor error."
- vog 11y agoNot sure why this has been downvoted. It is entirely correct to point out that counting the number of leading zeros is not the same as a less-than comparison. The less-than comparison is more fine-grained, while counting the number of leading zeros is just a nice approximation that is used for laymen explainations. For example, if your threshold is 00001011, you will accept "00001010" but not "00001100", despite both having the same number of (four) leading zeros.