Repository navigation
Revise Simplicity descriptors #108
Description
After recent years of updates to rust-simplicity and SimplicityHL, imo, it is not feasible to get Simplicity descriptors with policies back to life from the get-go, so instead we can take an iterative approach
First pack of changes that I would propose:
- Replace Simplicity policy leaves with
sim{asm(CMR)}and do not acceptsim{POLICY}syntax anymore (for the time being) - Add
descriptor::SimplicityLeaf<Pk>(Pk here is for future iteration for programs like P2PK, multisigs (?)) - Re-export the
simplicity-langcrate - Sanity check and lifting for Simplicity will fail with the error
Activity
apoelstra commentedon Sep 29, 2026
Yeah, concept ACK removing Simplicity policies for now (but leaving
asmwhich can be used for testing and to keep the two libraries integrated).For
descriptor::SimplicityLeaf<Pk>I'd prefer this be an alternate Tapleaf type rather than a top-level descriptor type. We may need to remove Simplicity, rebase this whole library (or at least the Taproot stuff) on a recent rust-miniscript, and then restore Simplicity to do this.KyrylR commentedon Sep 29, 2026
Is rust-miniscript ready? (I mean, is there any pending work that could impact Simplicity descriptors?)
apoelstra commentedon Sep 29, 2026
Yeah :/ we're in the middle of a pretty significant refactor of how we validate various "sanity" rules, and in the middle of a long-term project to remove recursion from the library, and we have 100+ LLM-reported issues to sift through.
Having said this, I suggest:
We can defer doing a wholesale rust-miniscript update, probably until we're past the rust-bitcoin 1.0 hump.
KyrylR commentedon Sep 30, 2026
Cool, thx
KyrylR commentedon Oct 1, 2026
KyrylR commentedon Oct 14, 2026
@apoelstra I have a question regarding the rust-miniscript's planning functionality:
AssetProviderandAssetsto describe signing capabilities.https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/plan.rs#L45
https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/plan.rs#L510
Witness placeholders and templates.
https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/miniscript/satisfy/mod.rs#L577
https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/miniscript/satisfy/mod.rs#L873
Tr::plan_satisfactionandTr::plan_satisfaction_mall.https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/descriptor/tr/mod.rs#L318-L331
Template completion using a
Satisfier.https://github.com/rust-bitcoin/rust-miniscript/blob/746bba5698a9ba34af0dc5bbfc6a05c167cf8a58/src/miniscript/satisfy/mod.rs#L1152
The upstream Taproot module depends on that planning infrastructure. Its concrete get_satisfaction also builds a template and completes it.
So, should the step
We then copy the Taproot module from rust-miniscript master.include those?apoelstra commentedon Oct 14, 2026
Oof. Yeah, I think we'll have to port all the planning infrastructure over to get Taproot stuff. (And I really think we have no choice about pulling the Taproot stuff over; our old API is nearly unusable and also buggy.)
I wonder if we should back up and instead attempt to "forward port" our existing covenant and simplicity stuff to rust-miniscript master, then setup a cronjob like with secp256k1-zkp to continually pull in upstream changes?