-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When are sanity_checks supposed to be run? #734
Comments
Curiously, in the |
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this issue
Sep 1, 2024
…= 12.x See rust-bitcoin#734 for discussion of this. Meanwhile, add a unit test so we can determine when the behavior changes.
apoelstra
added a commit
that referenced
this issue
Sep 3, 2024
1259375 miniscript: make display prefer 'u' over 'l' in the fragment l:0 (Andrew Poelstra) 67fdc50 descriptor: reject strings of the form "tr(<key>,)" (Andrew Poelstra) 00cac40 descriptor: add unit test demonstrating sanity-checking behavior in <= 12.x (Andrew Poelstra) Pull request description: This PR has three changes which are mostly unrelated except that they were all found when fuzzing my "rewrite expression parser to be nonrecursive" branch against 12.x. * First is a unit test demonstrating #734. It doesn't fix anything, just tests the current behavior. * Second is a fix for #736 (backported in #735). * Third tweaks the new `Display` code from #722 to change how the ambiguous `l:0`/`u:0` is serialized, to match 12.x. ACKs for top commit: sanket1729: ACK 1259375 Tree-SHA512: 921d65a1efd49bda0f9db488a2854b004e14518f584d832497a9dbc13a845ceec99544375385570c6ac42d4985277e8dcbb3aa8654de93235cf9067ba601f91d
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this issue
Sep 3, 2024
The `expression::Tree` type now parses expression trees containing both {} and () as children. It marks which is which, and it is the responsibility of FromTree implementors to make sure that the correct style is used. This eliminates a ton of ad-hoc string parsing code from descriptor/tr.rs, including 8 instances of Error::Unexpected. It is also the first change that preserves (sorta) a pubkey parsing error rather than converting it to a string. Because of rust-bitcoin#734 this inserts a call to `Descriptor::sanity_check` when parsing a string, specifically for Taproot descriptors. This is weird and wrong but we want to address it separately from this PR, whose goal is to preserve all behavior. This also introduces the new `error` module and `ParseError` enum, which we will move all string-parsing errors into. For now we just stick it in the big global enum, but eventually it will live on its own.
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this issue
Nov 13, 2024
The `expression::Tree` type now parses expression trees containing both {} and () as children. It marks which is which, and it is the responsibility of FromTree implementors to make sure that the correct style is used. This eliminates a ton of ad-hoc string parsing code from descriptor/tr.rs, including 8 instances of Error::Unexpected. It is also the first change that preserves (sorta) a pubkey parsing error rather than converting it to a string. Because of rust-bitcoin#734 this inserts a call to `Descriptor::sanity_check` when parsing a string, specifically for Taproot descriptors. This is weird and wrong but we want to address it separately from this PR, whose goal is to preserve all behavior.
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this issue
Nov 13, 2024
The `expression::Tree` type now parses expression trees containing both {} and () as children. It marks which is which, and it is the responsibility of FromTree implementors to make sure that the correct style is used. This eliminates a ton of ad-hoc string parsing code from descriptor/tr.rs, including 8 instances of Error::Unexpected. It is also the first change that preserves (sorta) a pubkey parsing error rather than converting it to a string. Because of rust-bitcoin#734 this inserts a call to `Descriptor::sanity_check` when parsing a string, specifically for Taproot descriptors. This is weird and wrong but we want to address it separately from this PR, whose goal is to preserve all behavior.
apoelstra
added a commit
to apoelstra/rust-miniscript
that referenced
this issue
Nov 23, 2024
The `expression::Tree` type now parses expression trees containing both {} and () as children. It marks which is which, and it is the responsibility of FromTree implementors to make sure that the correct style is used. This eliminates a ton of ad-hoc string parsing code from descriptor/tr.rs, including 8 instances of Error::Unexpected. It is also the first change that preserves (sorta) a pubkey parsing error rather than converting it to a string. Because of rust-bitcoin#734 this inserts a call to `Descriptor::sanity_check` when parsing a string, specifically for Taproot descriptors. This is weird and wrong but we want to address it separately from this PR, whose goal is to preserve all behavior.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On the
Miniscript
type, which users are not really supposed to use directly, we run sanity checks (e.g. all branches are "safe") onfrom_str
. You have to usefrom_str_ext
orfrom_str_insane
to override this.However, we don't do the same for
Descriptor::from_str
, which simply parses a tree then callsMiniscript::from_tree
, bypassing all sanity checks. So this seems backward -- by default for the users-shouldn't-use-this type we have sanity checks, while for descriptors, you have to manually call thesanity_check
method.However^2, for Taproot descriptors we do run the sanity checks on parsing, because we have bizarre special-purpose parsing logic which actually calls
Miniscript::from_str
for individual tapbranches rather than callingMiniscript::from_tree
.You can see this with the following unit test
We have the identical policy expressed as a
sh
(can parse no problem) or as atr
(will not parse, complains about the sigless `1( branch).The text was updated successfully, but these errors were encountered: