You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for 64-byte preimages and fixed witness markers #145
I’d be interested in @sipa 's thoughts on two possible extensions to Miniscript:
sha256(HEX), hash256(HEX) currently support 32 bytes preimages:
I'd like to extend support for both 32 byte or 64 byte preimages.
There's no support to have small arbitrary blobs of push data in witness: <expected_header> OP_EQUALVERIFY
I'd be interested in small amounts of bytes of arb push data to help facilitate little headers for transaction types for indexers to find when scanning the blockchain. (ex: a watchtower that looks for a 4 byte header).
@apoelstra this seems to be better in every way compared to what I suggested.
yes.
I'll move an issue over to rust-miniscript for the backlog. (I do have a question though about changes for BIP 379, any ideas around versioning miniscript? i.e. if bitcoin core may publicly only support version v1, while some wallets or rust-bitcoin may support v2)?
Thus far we have not needed to version Miniscript because all our changes have been strictly additive (and quickly propagated among all the implementations). That is, if you can parse a miniscript, you're upgraded enough.
It would be nice to add some metadata, including a version, maybe what chain the descriptor is for, hints about wildcard ranges, etc., but we've made no effort toward that.
Activity
apoelstra commentedon Oct 26, 2026
I wouldn't mind supporting different preimage lengths, maybe constrained to be between 16 and 64 inclusive.
For the pushdata, would
<data> OP_DROPbe sufficient for your usecase?apoelstra commentedon Oct 26, 2026
Once we get rust-miniscript in shape, I'd like to add a huge pile of nonstandard extensions. FWIW I'd be fine taking both of these.
miketwenty1 commentedon Oct 26, 2026
@apoelstra this seems to be better in every way compared to what I suggested.
yes.
I'll move an issue over to rust-miniscript for the backlog. (I do have a question though about changes for BIP 379, any ideas around versioning miniscript? i.e. if bitcoin core may publicly only support version v1, while some wallets or rust-bitcoin may support v2)?
apoelstra commentedon Oct 27, 2026
Thus far we have not needed to version Miniscript because all our changes have been strictly additive (and quickly propagated among all the implementations). That is, if you can parse a miniscript, you're upgraded enough.
It would be nice to add some metadata, including a version, maybe what chain the descriptor is for, hints about wildcard ranges, etc., but we've made no effort toward that.