rich1.0npub1u770f582qk4l6eagyv9jd2x7wqujlu9ckfka7ru9sgjqtxhlzq9s4ym47xhttps://nostr.ae/npub1u770f582qk4l6eagyv9jd2x7wqujlu9ckfka7ru9sgjqtxhlzq9s4ym47xnjumphttps://nostr.ae📅 Original date posted:2014-07-04 📝 Original message:On Fri, Jul 04, 2014 at 06:53:47AM -0400, Alan Reiner wrote: > Something similar could be applied to your idea. We use the hash of a > prevBlockHash||nonce as the starting point for 1,000,000 lookup > operations. The output of the previous lookup is used to determine > which block and tx (perhaps which chunk of 32 bytes within that tx) is > used for the next lookup operation. This means that in order to do the > hashing, you need the entire blockchain available to you, even though > you'll only be using a small fraction of it for each "hash". This might > achieve what you're describing without actually requiring the full 20 GB > of reading on ever hash. Anything involving lots of unpredictable memory accesses to a large chunk of fast memory is unASICable. That data vector could be derived by the same means as an one time pad, and loaded and locked into memory after boot. If you make it large enough it won't profit from embedded RAM bandwidth/speedup. The only way to speed up would be clustering, which doesn't offer economies of scale.