š
Original date posted:2014-07-04
š Original message:Hello,
I had a thought after reading Mike Hearn's blog about it being impossible to
have an ASIC-proof proof of work algorithm.
Perhaps I'm being dim, but I thought I'd mention my thought anyway.
It strikes me that he's right that it's impossible for any algorithm to exist
that can't be implemented in an ASIC. However, that's only because it's
trying to pick an algorithm that is CPU bound. You could protect against ASCI
mining (or rather, make it irrelevant that it was being used) by making the
algorithm IO-bound rather than CPU-bound.
For example, what if the proof-of-work hash for a block were no longer just
"hash of block", which contains the hash of the parent block, but instead were
hash of
[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]
[ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and
suffixing the new block, you have to feed every byte of the blockchain through
the hashing engine (the prefix prevents you caching the intermediate result).
Whatever bus you're using to feed your high speed hashing engine, it will
always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and
any hashing engine will, effectively, be the same.
I'm making the assumption that SHA-256 is not cacheable from the middle
outwards, so the whole block-chain _has_ to be transferred for every hash.
Apologies in advance if this is a stupid idea.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 15:23:33
in reply to nevent1qā¦g65v
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 15:23:33Event JSON
{
"id": "56f7c56f5b2a24fa56154bdfa89f2e87adcff975853e5b9c7ac30e97ca745520",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686151413,
"kind": 1,
"tags": [
[
"e",
"a9e20ae1b6e168ee862b71e56f89b4ed7603371912b3a24e648d19074482f62c",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
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",
"sig": "f8f3c57a4e6a982c14fbe70083be31acd223b04b7c9f170de0e3067041f777a5db861ec92cfd419f850e27736f0a7075046847754a8ed3999e9d7073cd8f70d7"
}