Descriptor syntax for hash preimages

A literal preimage within a descriptor ceases to be confidential once any output utilizing its hash branch is spent, as all outputs in a ranged descriptor share this branch. The hash fragments process a digest rather than a key expression, resulting in identical digests across all indices when using sha256(preimage(HEX)) in a /* descriptor. Upon spending through the hash path, the preimage becomes publicly accessible on the blockchain. While the s property maintains security for remaining outputs by requiring signatures for each, the hash condition loses its protective value after exposure.

In contrast, private keys retain their secrecy even after being used, as spending does not disclose them. Therefore, secrets akin to Wallet Import Format (WIF) only remain protected until their initial use. Generating deterministic preimages—deriving a unique preimage per output index from key material—can provide each output with a distinct digest, addressing concerns of shared exposure. Introducing such an approach would clarify the limitations of literal preimages and underscore the differences between private and public string checksums, similar to the treatment of keys. It is essential for the relevant Bitcoin Improvement Proposal (BIP) to explicitly document this distinction, since it introduces a novel aspect to hash fragments.

Currently, the btclib-wallet library, which is under active development, does not yet support the preimage(HEX) syntax. However, its parser already produces appropriate scripts for the digest form of all four fragment types. There are plans to implement support for the private form and to generate test vectors. Each private descriptor must yield the same script as one specified by the digest, and its public representation should display the corresponding digest.