{"type":"rich","version":"1.0","author_name":"npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv","author_url":"https://nostr.ae/npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-07-04\n📝 Original message:Hello,\n\nI had a thought after reading Mike Hearn's blog about it being impossible to \nhave an ASIC-proof proof of work algorithm.\n\nPerhaps I'm being dim, but I thought I'd mention my thought anyway.\n\nIt strikes me that he's right that it's impossible for any algorithm to exist \nthat can't be implemented in an ASIC.  However, that's only because it's \ntrying to pick an algorithm that is CPU bound.  You could protect against ASCI \nmining (or rather, make it irrelevant that it was being used) by making the \nalgorithm IO-bound rather than CPU-bound.\n\nFor example, what if the proof-of-work hash for a block were no longer just \n\"hash of block\", which contains the hash of the parent block, but instead were \nhash of \n\n   [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]\n\n[ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing.  By prefixing and \nsuffixing the new block, you have to feed every byte of the blockchain through \nthe hashing engine (the prefix prevents you caching the intermediate result).  \nWhatever bus you're using to feed your high speed hashing engine, it will \nalways be faster than the bus -- hence you're now IO-bound, not CPU-bound, and \nany hashing engine will, effectively, be the same.\n\nI'm making the assumption that SHA-256 is not cacheable from the middle \noutwards, so the whole block-chain _has_ to be transferred for every hash.\n\nApologies in advance if this is a stupid idea.\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com"}