cleanup: refactor a bunch of concatenation-related code in satisfy
#798
Conversation
This file contains 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
apoelstra
force-pushed
the
2025-03--satisfy
branch
from
5fd2dfd to
3c832b2
Compare
|
Heh, there's more clippy stuff to fix (I think I need to update my nightly..) but I am signing off for today. |
Clippy prefers we do string slicing after conversion to bytes, not before, which may be more efficient (at least, in elimantes some panic paths which we know are impossible since our strings are ASCII, but the compiler probably doesn't). It also changes some nested lists in docs to use 1/2/3 numbering because that's what rustdoc recognizes (and clippy complains about weird indentation with the existing a/b/c sublist).
There is a bunch of essentially-repeated "combine two satisfactions" code throughout satisfy.rs. It's hard to tell at a glance what order the concatenantions are in, even though this is essential, or whether the combination is actually done correctly. (In particular, we routinely use the opposite order for Witness::combine and for ||'ing the has_sig, and we routinely assume that timelock conditions are None for dissatisfactions, which is true, but it's still a lot to keep in your head.)
This commit adds a `miniscript_satisfy` target which includes a fair bit of infrastructure to generate fuzz data (specifically cheap public keys which are easy to put into a string, and also a satisfier). Arguably this stuff should be pulled out of the fuzz test into a library. Punting on that until later when we move to cargo-fuzz.
apoelstra
force-pushed
the
2025-03--satisfy
branch
from
3c832b2 to
426479d
Compare
|
This one should be good to go and have a green CI. I'll start working on a followup which ports the rust version pinning from rust-bitcoin which should make CI stop breaking. Then since I'm thinking about this crate I'll take a look at what the status of my "eliminate recursion / fix errors / replace ctx" projects are and see if I can't do another PR.. |
apoelstra
added a commit
that referenced
this pull request
Apr 1, 2025
…ated code in satisfy 9d81dcf bump version to 12.3.1 (Andrew Poelstra) 7be767c satisfy: clean up a bunch of satisfaction code (Andrew Poelstra) 8efce62 ci: fix new clippy lint related to doccomments (Andrew Poelstra) Pull request description: This backports the main commit in #798 so that the code in (released) 12.x is substantially the same as the code in (unreleased) 13.x. This makes it easier to write and maintain regression tests. ACKs for top commit: sanket1729: ACK 9d81dcf Tree-SHA512: 1996ba4e2d01fc469e43724d7c6b2fbd5d1536181501ecb71ae99566bf7f635e829cfb7383d22241226becc84fcb95efcd105c95e165a401e9bd31e89e89ff19
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There is a bunch of essentially-repeated "combine two satisfactions" code throughout satisfy.rs. It's hard to tell at a glance what order the concatenantions are in, even though this is essential, or whether the combination is actually done correctly.
In particular, we routinely use the opposite order for Witness::combine and for ||'ing the has_sig, and we routinely assume that timelock conditions are None for dissatisfactions, which is true, but it's still a lot to keep in your head.
Also adds a fuzz test to sanity check our satisfactions (just checks for crashes; we don't check whether satisfaction "should" succeed since that's hard to tell in general.)