Oops, forgot to reply to your last point. Indeed, we could push for more place by just always having one 0-byte, but I'm not sure the added complexity helps anything? ASICs can never be designed which use more extra-nonce-space than what they can reasonably assume will always be available, so we might as well just set the maximum number of bytes and let ASIC designers know exactly what they have available. Currently blocks start with at least 8 0-bytes. We could just say minimum difficulty is now 6 0-bytes (2**16x harder) and reserve those? Anyway, someone needs to take a closer look at the midstate optimization stuff to see what is reasonable required.
Matt >>> 4) Instead of requiring the first four bytes of the previous block hash >>> field be 0s, we allow them to contain any value. This allows Bitcoin >>> mining hardware to reduce the required logic, making it easier to >>> produce competitive hardware [1]. >>> [1] Simpler here may not be entirely true. There is potential for >>> optimization if you brute force the SHA256 midstate, but if nothing >>> else, this will prevent there being a strong incentive to use the >>> version field as nonce space. This may need more investigation, as we >>> may wish to just set the minimum difficulty higher so that we can add >>> more than 4 nonce-bytes. >> >> Could you just use leading non-zero bytes of the prevhash as additional >> nonce? >> >> So to work out the actual prev hash, set leading bytes to zero until >> you hit a zero. Conversely, to add nonce info to a hash, if there are >> N leading zero bytes, fill up the first N-1 (or less) of them with >> non-zero values. >> >> That would give a little more than 255**(N-1) possible values >> ((255**N-1)/254) to be exact). That would actually scale automatically >> with difficulty, and seems easy enough to make use of in an ASIC? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
