use hex-conservative 1.0 everywhere for decoding#822
Merged
Conversation
Member
Author
|
Drafting. Might as well just wait for the real 1.0. |
apoelstra
force-pushed
the
push-ppmrkrkvqkzo
branch
3 times, most recently
from
fb0adc3 to
bea8cde
Compare
Member
Author
|
Published :) will update this tonight or tomorrow morning. |
apoelstra
force-pushed
the
push-ppmrkrkvqkzo
branch
from
bea8cde to
78e8f01
Compare
tcharding
approved these changes
Jul 15, 2025
Member
|
PR title and git log are both stale - they mention 'rc'. |
tcharding
reviewed
Jul 15, 2025
| } | ||
| } | ||
| } | ||
| use miniscript::hex; |
tcharding
reviewed
Jul 15, 2025
Comment on lines
-74
to
+73
| let depo_tx: Transaction = deserialize(&Vec::<u8>::from_hex(hex_tx).unwrap()).unwrap(); | ||
| let depo_tx: Transaction = deserialize_hex(hex_tx).unwrap(); |
Member
There was a problem hiding this comment.
This is kind of an unrelated change, bad Andrew no biscuit.
Member
Author
There was a problem hiding this comment.
How is it unrelated? We used to have a hex library that has from_hex and now we don't.
Member
There was a problem hiding this comment.
oooph - I'm a spastic. I did not even look inside the function call to deserialize only at the function name changes - ouch.
tcharding
reviewed
Jul 15, 2025
Comment on lines
-1658
to
+1657
| Vec::<u8>::from_hex("76a91479091972186c449eb1ded22b78e40d009bdf008988ac").unwrap()[..] | ||
| hex::decode_to_vec("76a91479091972186c449eb1ded22b78e40d009bdf008988ac").unwrap()[..] |
Member
There was a problem hiding this comment.
Out of interest did you find yourself cursing the f***ing hex-conservative devs or were you happy enough during the upgrade?
Member
Author
There was a problem hiding this comment.
I was happy enough, but the lack of encoding support is idiotic.
apoelstra
changed the title
It turns out we only ever use do decoding of fixed test vectors. It would be nice to have a hex! macro for this. Eventually. In some cases we were able to use inherent methods on bitcoin types -- for example ScriptBuf::from_hex or deserialize_hex.
apoelstra
force-pushed
the
push-ppmrkrkvqkzo
branch
from
78e8f01 to
a1fa898
Compare
tcharding
approved these changes
Jul 17, 2025
Member
Author
|
Going to merge this one -- in general, I don't want to move rust-miniscript to 1.0 dependencies on the main branch because I have been hyping up "Miniscript 13" to people out-of-band and want the next release to be compatible with bdk. But in the case of hex-conservative, the only "1.0 types" that are expose are error types, so it's okay. |
heap-coder
added a commit
to heap-coder/rust-miniscript
that referenced
this pull request
Sep 27, 2025
…ywhere for decoding
a1fa898f9f164baee2eca787b06fd89ea10f880d use hex-conservative 1.0 everywhere for decoding (Andrew Poelstra)
Pull request description:
It turns out we only ever use do decoding of fixed test vectors. It would be nice to have a hex! macro for this. Eventually.
In some cases we were able to use inherent methods on bitcoin types -- for example ScriptBuf::from_hex or deserialize_hex.
ACKs for top commit:
tcharding:
ACK a1fa898f9f164baee2eca787b06fd89ea10f880d
Tree-SHA512: 234fb4974e86b6b72d3f0aaefbe7f1ea73cfd90c0152c163d3f0b46e94d50f3e784f5499e00b058736b242b1c0dde39b41d5a2583319bf9c580a0db84dc24237
nyonson
pushed a commit
to rust-bitcoin/rust-psbt
that referenced
this pull request
Jun 4, 2026
* build: bump miniscript to 13.0.0 | * ci: allow hex-conservative duplicates | * miniscript: replace decode_with_ext(., Ext::allow_all) with decode_consensus | | Currently we have decode() and decode_insane() (which were both called | parse_* before PR #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). | | Port from rust-bitcoin/rust-miniscript#871 | * miniscript: rename parse_* functions to decode_* | | 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). | | Port from rust-bitcoin/rust-miniscript#845 | * miniscript: use hex-conservative 1.0 everywhere for decoding | | It turns out we only ever use do decoding of fixed test vectors. It | would be nice to have a hex! macro for this. Eventually. | | In some cases we were able to use inherent methods on bitcoin types -- | for example ScriptBuf::from_hex or deserialize_hex. | | Port from rust-bitcoin/rust-miniscript#822 | * key(miniscript): replace ConversionError with NonDefiniteKeyError | | The new error type is now more descriptive and a strict superset | of the old one. Furthermore, the new name is more appropriate since | this error typically arises during construction of a DefiniteDescriptorKey | rather than during conversion between different key types. | | Port from rust-bitcoin/rust-miniscript#839 | | keys(miniscript): remove impossible unwrap()s | | Now that we are consistent about the rules that a DerivedDescriptor must | obey, we no longer return a Result from derived_key(), which in turn | eliminates a bunch of other unwraps. | | Port from rust-bitcoin/rust-miniscript#839 | * macros(miniscript): make target pk and error type optional for translate_* macros | | There is no reason callers need to provide these types explicitly. Allow | them to do so anyway for backward compatibility. | | Port from rust-bitcoin/rust-miniscript#839 | * tr(miniscript): add conversion from TrSpendInfo to bitcoin::TapTree | | Moves a bit of ugly logic out of the PSBT module into the spendinfo | module so that it's available for other users. We can convert from a | TrSpendInfo to a bitcoin::TapTree but we can't do the opposite | conversion since TrSpendInfo expects to have a Miniscript for each leaf. | | Port from rust-bitcoin/rust-miniscript#815 | * tr(miniscript): replace `bitcoin::TaprootSpendInfo` with `TrSpendInfo`, update psbt | | This commit stops using the rust-bitcoin `TaprootSpendInfo` in favor of | our new `TrSpendInfo` structure. This one allows us to iterate over all | the leaves of the Taptree, easily accessing their leaf hashes and | control blocks in order, which simplifies satisfaction logic. | | Port from rust-bitcoin/rust-miniscript#815 | * psbt(miniscript): untangle some logic in `update_item_with_descriptor_helper` | | We have the function `update_item_with_descriptor_helper` which does a | few things: it derives a descriptor (replacing all the xpubs with actual | public keys) and updates the appropriate input or output map to map the | derived keys to their keysources. | | It treats Tr outputs differently from other kinds of outputs, because | the relevant maps are different. However, in doing so, it duplicates a | bunch of work in ways that are hard to follow. | | Essentially, the algorithm does three things: (a) derives all the keys | (and the descriptor), (b) optionally checks that the resulting | scriptpubkey is what we expect, and (c) updates the maps. The existing | code handles (a) separately for Tr and non-Tr descriptors. | | In the Tr case, we derive all the keys using | Descriptor::<DescriptorPublicKey>::derived_descriptor which derives all | the keys and throws away the conversion. Then separately it keeps around | the un-derived descriptor, iterates through the keys, and populates the | `tap_key_origins` map by re-computing the derivation. | | In the non-Tr case, we derive all the keys using the `KeySourceLookUp` | object, which does exactly the same thing as `derived_descriptor` except | that it stores its work in a BTreeMap, which is directly added to the | PSBT's `item.bip32_derivation` field. | | This commit pulls out (a) into common code; it then copies all the data | out of the key map into `item.tap_key_origins` along with an empty | vector of tapleaves. It then goes through all the leaves, and for each | key that appears in each leaf, appends that leaf's hash to the vector of | tapleaves. This is still a little ineffecient but will be much cleaner | after a later commit when we improve the Taproot SpendInfo structure. | | The original code dates to Lloyd's 2022 PR #339 which introduces logic to | populate these maps. That algorithm underwent significant refactoring in | response to review comments and I suspect that the duplicated logic went | unnoticed after all the refactorings. | | Port from rust-bitcoin/rust-miniscript#815 | * satisfy(miniscript): change `lookup_tap_key_spend_sig` to take the public key | | There is only one public key possible, but this makes the API more | consistent between keyspends and script-spends, and makes it much | easier for users who have a key->sig lookup table to implement | satisfiers. | | Fixes rust-bitcoin/rust-miniscript#825 | | Port from rust-bitcoin/rust-miniscript#827 | * tr(miniscript): rename `iter_scripts` to `leaves` | | The name `iter_scripts` is dumb and undiscoverable. More importantly, | it's misleading -- this iterator does not yield scripts. It yields | Miniscripts, which can be converted to scripts if you have ToPublicKey | and are willing to pay a cost. | | Port from rust-bitcoin/rust-miniscript#807 | * tr(miniscript): encapsulate object yielded by TapTreeIter | | All this does is wrap the existing (depth, script) return value in a | structure that has a pile of accessors on it. The accessors include | a couple of expensive computations which are currently done manually. | | Port from rust-bitcoin/rust-miniscript#807 | * translator(miniscript): remove `TranslatePk` trait and clean up `Translator` trait | | This is an annoying breaking change for users of the Translator trait | but I think it greatly improves the ergonomics of using the trait. | Rather than having it be parameterized over 3 types, it is now | parameterized over just one (the "source pk type"). | | This matches how this trait is used in practice -- you typically have a | miniscript/policy/whatever with a keytype Pk, and you want to use a | translator from Pk to "whatever the translator maps to" with "whatever | error the translator yields". So the only type parameter you really need | to type is Pk; the others are irrelevant, and making the user name and | type them is annoying. | | Since this eliminates the need to explicitly write out the error types | except when actually implementing the trait, this also changes a ton of | error types from () to Infallible, which is more efficient and correct. | | Port from rust-bitcoin/rust-miniscript#733
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
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.
It turns out we only ever use do decoding of fixed test vectors. It would be nice to have a hex! macro for this. Eventually.
In some cases we were able to use inherent methods on bitcoin types -- for example ScriptBuf::from_hex or deserialize_hex.