Descriptor syntax for hash preimages

The discussion revolves around enhancing Bitcoin's descriptor capabilities to include secrets of miniscript hash fragments, similar to how private keys are handled. Current descriptors support public and private key forms but do not accommodate the preimages required for hashing functions like sha256 or hash160. This limitation was evident when attempting a transaction that necessitated providing a hash preimage, a feature not supported by Bitcoin Core's wallet infrastructure. The proposal suggests introducing a format whereby descriptors can store hash preimages, which would then be encrypted and managed alongside keys within a wallet.

A potential extension to BIP 379 is considered, which would introduce syntaxes such as sha256(preimage(HEX)), and ensure that these preimages are handled securely within the wallet environment, akin to private keys. The proposed format mandates that a preimage must strictly be 32 bytes to match existing script requirements, addressing both functionality and security concerns. The inclusion of preimages in descriptors could simplify processes where these elements act more like keys than signatures, given their independence from specific transactions and long-lived nature.

However, several open questions remain regarding the implementation specifics, such as the exact syntax for incorporating preimages into descriptors, whether this should be an amendment to an existing BIP or a new standalone proposal, and how hardware wallets might interact with this new feature. Additionally, there's consideration of whether future developments should allow for deriving preimages from key material, echoing methods used in solutions like the Lightning Network.

This proposal has sparked discussions across various platforms, suggesting a broader interest and potential for evolving how Bitcoin handles transaction elements beyond mere signatures. Links to related discussions and proposals can be found at Tr(): rawnode() and rawleaf() support, Unspendable keys in descriptors, and BIP352 private key formats. These contributions highlight ongoing efforts to refine and enhance the scripting and transaction capabilities of Bitcoin, aiming for a more flexible and secure framework.