various improvements/refactors of the decoder and its errors #845
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a little less space efficient but it gets rid of a lifetime parameter on the lexer token, which is annoying because it prevents us from putting it into error types. (Currently we convert it to a string before putting it into an error.) It also eliminates a whole bunch of panics where we convert slices to hashes and .expect() on the length being right, when we know it's right.
Also clean up the names and format messages for them.
…onstructors We have infallible constructors for all the terminals except multi/multia. We should use them and eliminate a bunch of error paths.
The word "parse" is redundant at best, and wrong at worst (we use "decode" when converting a script and "parse" when converting a string). The variants were also overly verbose and the formatting text lost information. Clean all this up.
We should backport this one to 12.x (with a deprecation). Would also be open to doing a deprecation here in master. But this has been bugging me for years, and also it's much less common to decode miniscript from script than we imagined back in 2018. Provides symmetry with encode() and consistency with the docs (though this PR does not fix up the docs).
apoelstra
force-pushed
the
2025-07/decode
branch
from
5cca410 to
cdb36c1
Compare
heap-coder
added a commit
to heap-coder/rust-miniscript
that referenced
this pull request
Sep 27, 2025
…s of the decoder and its errors
cdb36c19b536ef8d8716dd1423e7e6b96433101e miniscript: rename parse_* functions to decode_* (Andrew Poelstra)
5fea2b3cee70f02b18f1d6fbba7b777ab329e7b1 miniscript: rename and cleanup decode::KeyParseError (Andrew Poelstra)
a57fab3ca26a20140a90b8ca66408c9246fdf9cd miniscript: replace many calls to reduce0 in decode with infallible constructors (Andrew Poelstra)
5b736bdede89b15866659c4d38383db4af4240cd miniscript: move lexer errors into their own type (Andrew Poelstra)
ceadd0d4d98bf8f7bc2a80f1727769cb9e442f9a miniscript: use byte arrays in lexer (Andrew Poelstra)
Pull request description:
The last commit, which renames `parse_with_ext` to `decode_with_ext`, I think we should backport with deprecation to 12.x. This is a pretty uncommonly used function and is unlikely to bother anybody, but the current name is inconsistent with our general use of "parse" for strings and "decode" for scripts.
ACKs for top commit:
sanket1729:
ACK cdb36c19b536ef8d8716dd1423e7e6b96433101e
Tree-SHA512: 8a3563dd23e49cf9331b299e237337a3d1097c15d5fe143ec9aa3f686d681fda077f019b25f0d66fccdd9a88ec489a84e144fcbb28410a671eb113f38e0fe58d
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this pull request
Oct 20, 2025
…nsensus Currently we have decode() and decode_insane() (which were both called parse_* before PR rust-bitcoin#845). In practice though, throughout the codebase we see that when decoding from script we want to relax more than sanity. In particular, we frequently with ExtParams::allow_all, which beyond relaxing the sanity rules, also allows raw pubkeyhashes. We do this in the script interpreter and in PSBT, on the basis that once we're working with a script, we should just deal with whatever the library is capable of dealing with. (Is this the right decision? IMO yes. It could be argued. But regardless, it's the decision we've made for the past many versions of rust-miniscript.) I also propose to backport this with deprecation, telling users that if they really want parse_insane, they now need to call decode_with_ext and specify ExtParams::insane. But if their goal was "parse anything that might be allowed", they actually want decode_consensus. There is now an asymmetry between parsing from string and parsing from script: with strings we have parse() and parse_insane(). With script we have decode() and decode_consensus(). I think this is correct, and reflects the fact that somebody "breaking the rules" with a string is likely trying to use syntactically valid Miniscripts without the library whining at him, while somebody "breaking the rules" with a Script is probably trying to deal with some immutable on-chain thing and wants the library to work if at-all possible. Right now the distinction is simply "do we support raw pkh or not" but I think we could accept more-or-less arbitrary extensions to Miniscript in this library that worked the same way (allowed when decoded from script but disallowed from strings since there's no serialization).
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this pull request
Oct 26, 2025
…nsensus Currently we have decode() and decode_insane() (which were both called parse_* before PR rust-bitcoin#845). In practice though, throughout the codebase we see that when decoding from script we want to relax more than sanity. In particular, we frequently with ExtParams::allow_all, which beyond relaxing the sanity rules, also allows raw pubkeyhashes. We do this in the script interpreter and in PSBT, on the basis that once we're working with a script, we should just deal with whatever the library is capable of dealing with. (Is this the right decision? IMO yes. It could be argued. But regardless, it's the decision we've made for the past many versions of rust-miniscript.) I also propose to backport this with deprecation, telling users that if they really want parse_insane, they now need to call decode_with_ext and specify ExtParams::insane. But if their goal was "parse anything that might be allowed", they actually want decode_consensus. There is now an asymmetry between parsing from string and parsing from script: with strings we have parse() and parse_insane(). With script we have decode() and decode_consensus(). I think this is correct, and reflects the fact that somebody "breaking the rules" with a string is likely trying to use syntactically valid Miniscripts without the library whining at him, while somebody "breaking the rules" with a Script is probably trying to deal with some immutable on-chain thing and wants the library to work if at-all possible. Right now the distinction is simply "do we support raw pkh or not" but I think we could accept more-or-less arbitrary extensions to Miniscript in this library that worked the same way (allowed when decoded from script but disallowed from strings since there's no serialization).
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this pull request
Oct 26, 2025
…nsensus Currently we have decode() and decode_insane() (which were both called parse_* before PR rust-bitcoin#845). In practice though, throughout the codebase we see that when decoding from script we want to relax more than sanity. In particular, we frequently with ExtParams::allow_all, which beyond relaxing the sanity rules, also allows raw pubkeyhashes. We do this in the script interpreter and in PSBT, on the basis that once we're working with a script, we should just deal with whatever the library is capable of dealing with. (Is this the right decision? IMO yes. It could be argued. But regardless, it's the decision we've made for the past many versions of rust-miniscript.) I also propose to backport this with deprecation, telling users that if they really want parse_insane, they now need to call decode_with_ext and specify ExtParams::insane. But if their goal was "parse anything that might be allowed", they actually want decode_consensus. There is now an asymmetry between parsing from string and parsing from script: with strings we have parse() and parse_insane(). With script we have decode() and decode_consensus(). I think this is correct, and reflects the fact that somebody "breaking the rules" with a string is likely trying to use syntactically valid Miniscripts without the library whining at him, while somebody "breaking the rules" with a Script is probably trying to deal with some immutable on-chain thing and wants the library to work if at-all possible. Right now the distinction is simply "do we support raw pkh or not" but I think we could accept more-or-less arbitrary extensions to Miniscript in this library that worked the same way (allowed when decoded from script but disallowed from strings since there's no serialization).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The last commit, which renames
parse_with_exttodecode_with_ext, I think we should backport with deprecation to 12.x. This is a pretty uncommonly used function and is unlikely to bother anybody, but the current name is inconsistent with our general use of "parse" for strings and "decode" for scripts.