Posted by nofetiko
Oct 26, 2026/20:36 UTC
A distinction must be made between simply matching the 80-byte block header layout and achieving direct mineability using existing SHA256d ASIC hardware. Although the structural alignment with the typical block header format might suggest compatibility, there are additional commitments within the hashed preimage that go beyond this superficial similarity.
The preimage, in this scenario, incorporates not only the standard fields but also prefix and suffix length commitments. Furthermore, the validation process involves computing a double-SHA256 hash of this preimage, which is then checked by the script. This raises an important question about nonce manipulation: whether it is feasible for a standard miner to vary the nonce in the way expected by ASIC miners while maintaining the integrity of the preimage as required by the protocol.
Given these requirements, using off-the-shelf SHA256d ASICs for mining may not be straightforward, even if the fields align with those of a block header. The presence of additional commitments in the preimage structure likely necessitates a custom work generator capable of handling these constraints. Therefore, compatibility with existing mining hardware depends not just on field alignment, but also on the miner’s ability to produce valid preimages according to these extended rules.
Thread Summary (11 replies)
Jun 3 - Oct 27, 2026
12 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback