Timeline for Why change the nonce instead of just rehashing?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 22, 2016 at 1:12 | comment | added | Glenn | Thank you very much @DavidSchwartz . With this question, I feel I might have ventured into blockchain specifics too early in my context of understanding to already be asking 'what if' questions. But this did contribute to my understanding. Many thanks to both cdecker and you. | |
| Feb 22, 2016 at 0:48 | comment | added | David Schwartz | The point of the PoW is to secure the block chain. Just proving you did work is not helpful, that work must be tied to the particular block you're securing. | |
| Feb 22, 2016 at 0:46 | comment | added | Glenn | @DavidSchwartz Thank you for weighing in David. Could you elaborate on what you mean? I hadn't read about the PoW securing the claimed block is what needs to be verified (at least not in those words). | |
| Feb 21, 2016 at 22:01 | comment | added | David Schwartz | @Glenn You could verify the PoW with but a single hash. But that wouldn't verify that the PoW in fact secures the claimed block, which is what you need to verify. | |
| Feb 21, 2016 at 17:15 | vote | accept | Glenn | ||
| Feb 21, 2016 at 17:15 | comment | added | Glenn | Thank you cdecker. I thought that verifying a PoW consisted of only performing a single hash operation to check whether the issuer's 'solution' resulted in a valid output (in which case, both scenarios -altering input and the iterative case- would require the same amount of work to verify). From your answer I gather that the entire work (or at least logic behind the 'solution') also needs to be verified. | |
| Feb 21, 2016 at 17:01 | comment | added | cdecker | He could not connect the header to the pre-image that is being passed along, this would allow an intermediary node to modify the header arbitrarily without invalidating the proof-of-work. So let's say SHA256(...n-1 times...(header) ...) is the preimage of SHA256(...n times...(header)...) which is a PoW, then the verifier would be able to verify that SHA256(pre-image) is a PoW but not that this pre-image is n-1 nested SHA256 calls on the header without actually doing these calls. | |
| Feb 21, 2016 at 16:54 | comment | added | Glenn | Thank you cdecker. Just trying to wrap my head around the would-be verification In the iterative case...RE: your previous comment - if the verifier takes the block header and the issuer's final hash, wouldn't one hash operation also be enough? In that case, the verifier would have all necessary input (blockheader + the issuer's final hash) and one single hash operation would allow the verifier to check the resulting output and see if it's valid, no? | |
| Feb 21, 2016 at 16:42 | comment | added | cdecker | Exactly, that's the difference between altering the input (verifier just takes PoW, hashes and checks the output) and the iterative case (verifier would have to take block header and hash it exactly the same number of times as the issuer did). | |
| Feb 21, 2016 at 16:26 | comment | added | Glenn | Thank you @cdecker . That makes sense. Could you explain what you mean with "when varying the input this does not happen since given the input the verifier can perform a single hash operation and check the result"? Isn't a single hash operation always enough for verification? | |
| Feb 21, 2016 at 16:09 | history | answered | cdecker | CC BY-SA 3.0 |