Hacker News Reader

Comment by aviaviavi | Hacker News Reader

Correct, the goal for this was as minimal as possible.

However, if I (or anyone wanting to contribute) can come up with a very compact way to implement that, we could definitely add it!

View on HN

A very simple proof of work is adding a token to the data before hashing:

sha256(token + data + previous hash)

i.e. (for simplicity, previous hash = "")

sha256("1" + "example" + PreviousHash) -> ee73735c2355bc4d63319a6638e356ef42d0d56746317c99f52d3e7ac71cbf52

sha256("2" + "example" + PreviousHash) -> 6236cd42286c74a1683eaf394b3b2f40a3a52479e1a3d7e732175fcdfa49b931

...

sha256("10" + "example" + PreviousHash) -> 346fea90403e733fd6e925920eb10be06171b4f77f7cc8c4ef214a12f04d79c1

And only accepting hashes as valid where the first two characters form "34". So the last example (token 10) would be valid. This requires then to do multiple hashing operations until a valid hash emerges, thus the proof of work.

Note that "the first X characters" is kind of misleading, because it is usually more fine grained.

It is better (and IMHO even simpler!) to think of the hash as a large integer, not a string. Then you want that integer to be smaller than a certain value.

With strings, you can only say: "00123" shall start with "00", while wih integers, you would say: 00123 shall be smaller than 300.

(To be that fine grained with strings, you would either need multiple prefixes ("000", "001", "002") regexes ("00[012]"), both more hassle than a simple less-than operation.)

I agree with the gist, but note that even with strings, "00122" is less than "00200" :)

Oh, you are right! However, my point still stands that this is not about prefixes, but about a less-than comparison.

You can implement 0 prefix checking pretty easily in bitstrings:

    0 == hash >> (hash_length - prefix_length)

Or, alternatively:

    !(hash & prefix_mask)

where `prefix_mask` is 1111..000, with `prefix_length` number of 1s.

I think that working in terms of bitstrings generated by the hash gives more context to why those integers are chosen (that they represent a certain portion of the space of possible answers), but it's also a matter of taste/background.

This is still more combersome yet less precise than a straight greater-than check.

Thanks for simple explanation! Maybe between myself and perhaps 18nleung we can get a simple version of this in there

To implement rudimentary proof of work, you could add a nonce field and then force every block hash to start with a certain number of zeroes - I'll see what I can do and submit a pull!

Awesome, please do!

Reply on news.ycombinator.com