4 ms·

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 = "") sha2

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.

aviaviavi 9y ago
Thanks for simple explanation! Maybe between myself and perhaps 18nleung we can get a simple version of this in there
vog 9y ago
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.)
- jstanley 9y ago
  I agree with the gist, but note that even with strings, "00122" is less than "00200" :)
  - vog 9y ago
    Oh, you are right! However, my point still stands that this is not about prefixes, but about a less-than comparison.
- SomeStupidPoint 9y ago
  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.
  - vog 9y ago
    This is still more combersome yet less precise than a straight greater-than check.
deleted 9y ago
[deleted]

aviaviavi 9y ago

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

vog 9y ago

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.)

jstanley 9y ago
I agree with the gist, but note that even with strings, "00122" is less than "00200" :)
- vog 9y ago
  Oh, you are right! However, my point still stands that this is not about prefixes, but about a less-than comparison.
SomeStupidPoint 9y ago
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.
- vog 9y ago
  This is still more combersome yet less precise than a straight greater-than check.

deleted 9y ago

[deleted]