Proposal would let Bitcoin descriptors carry hash preimages the way they carry keys

Victoria Shinder04 October 2026, 13:002 min read

A post on Delving Bitcoin on 4 October proposes extending output descriptors so they can hold the secret behind a miniscript hash lock, not only its hash. The suggested syntax is sha256(preimage(HEX)), with the same form for hash256, ripemd160 and hash160, possibly as a new BIP extending BIP 379, the miniscript descriptor specification.

The gap. A descriptor can already carry a private key, written as pk(WIF) or with an xprv, and listdescriptors returns it with private=true. There is no equivalent for a preimage. The author ran into this solving a TABConf challenge that required revealing one: Bitcoin Core's wallet had no way to accept it, and the only route was inserting the PSBT_IN_SHA256 field, or one of the other hash fields, with an external tool before walletprocesspsbt or finalizepsbt could complete the witness.

The argument. A signature commits to a particular transaction, so it can never live in a descriptor. A preimage, once generated or handed over, depends only on the script and stays valid indefinitely, which, the post argues, makes it the same kind of long-lived secret as a private key. It quotes an earlier Bitcoin Core discussion that descriptors could eventually replace most of the wallet's signing data, everything except signatures and preimages, and calls the preimage exception unnecessary.

How it would work.

• All four hash fragments compile to a script that first checks the satisfaction is 32 bytes, so a valid preimage is always exactly 32 bytes, even for ripemd160 and hash160. Any other length would be rejected by the parser.
• The parser hashes the preimage and builds the same node as the digest form, so the script, its type and the witness size do not change, and dissatisfying the fragment still needs no secret.
• An explicit preimage(...) marker is required, because for sha256 and hash256 a raw 32-byte hex string could be either the preimage or the digest.
• The public form of the descriptor prints the digest; only the private form prints the preimage. In Bitcoin Core, preimages would be stored and encrypted alongside keys and given to the miniscript satisfier.

Limits. Preimages learned at spend time, such as one received from a counterparty in an HTLC, would still go through PSBT fields. The post also notes that a revealed preimage is public, but well-formed miniscript requires a signature on every spending path, so a preimage alone never spends. Open questions are the marker syntax and whether this belongs in BIP 379 or a separate BIP.

What it means

This is a design discussion, not code. For wallets built on miniscript, hash locks are common in timelocked recovery and swap scripts, and today their secrets live outside the backup that holds the keys. A descriptor that can carry both would make such wallets restorable from one string, which also means that string needs the same protection as a seed.