RFC: Miniscript integration #18040

Moving the discussion from #17975 here as adding Miniscript support to the TestFramework is only a subset of broader Miniscript integration in Core and shouldn't disrupt review of that PR.

1. Does Bitcoin Core need to be able to recognize Miniscript in the future? Are the future upsides sufficiently material to introduce it? Presumably Miniscript could always be translated to Script externally to Core at little cost?

Tentatively, there seems to be strong benefits to Core being able to recognize and analyze Miniscript such as the Core wallet being able to create a valid witness for Miniscript.

2. Is this a stepping stone towards greater support for Miniscript (and possibly a policy language too) in Core? What impact does this have on the use and ongoing development of external libraries like the Rust Miniscript library?

Tentatively, I would guess external Miniscript libraries like rust-miniscript will have more Miniscript capability/features than will be introduced to Core. The C++ implementation is "Core compatible". I'm assuming the plan is that this will broadly slot into Core (assuming there is consensus, sufficient review) given the open PR #16800.

Disclaimer: Some of this may be obvious to some (apologies if so!) but at the very least this will be educational for people like me who are curious about what should be in Core and what should be left for external Miniscript libraries.

Personally I'd love to see Miniscript support in Core! The Miniscript C++ implementation hasn't seen any repo activity since September 2019, but I hope there will be renewed activity soon :)

I would like to see Miniscript fully integrated into Core. The plan with Descriptor wallets is that we can extend them in the future to also store Miniscript. So then we would have a wallet which can produce addresses for arbitrary scripts and be able to sign for them.

I asked @apoelstra about Miniscript in Core at his London Bitcoin Devs talk on Miniscript. A summary (paraphrasing) of his response.

Core should have the ability to sign for Miniscripts and to recognize Miniscripts it has control over. There are plans for Core to support Miniscript in the descriptor wallet which directly implies Core has to be able to finalize and sign them. A general PSBT finalizer effectively means there is a RPC where you give it a PSBT and Core is able to output a transaction.

The Policy to Miniscript compiler should not be in Core. That doesn’t even necessarily have a canonical design. There are some interesting fee estimation and analysis tooling that probably don’t belong in Core. Those probably belong in their own library or their own RPC tool or something like that. Core should be able to estimate fees for its own stuff but you probably shouldn't be able to ask whether keys are available or trusted in Core due to complex scenarios that only Miniscript is designed to address.

Full transcript: https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-02-04-andrew-poelstra-miniscript/

I agree the policy compiler doesn't belong in Core.

I'm not sure about fee estimation; once we have descriptor wallets (with miniscript integration) there isn't really a difference between "miniscript" and "core's own stuff". Once we have a workable solution for doing spending size estimation, it can be implemented in the C++ library, which can be included in Core (see #16800).

Just wanted to chime in that for my own development purposes I'd love to see the ability to define wallets with miniscript in Core; I'm ambivalent as to the specific level of integration. At the moment custom scripting is far more onerous than it should be, in my opinion.

There has been some recent discussion (July 16th Core wallet meeting) on both the progress status of Miniscript in Core and upgrading Miniscript to support Taproot.

The focus appears (at least for the C++ implementation of Miniscript) to be getting Miniscript into Core in its current form before considering upgrading Miniscript to support Taproot. PR 16800 has been languishing for a while, needs a significant rebase and an uptick in review.

The idealized (medium/long term) plan would be to get #16800 merged, Miniscript upgraded to support Taproot, upgraded Miniscript merged into Core and then the Core wallet could potentially support spending from generic scripts in the leaves of a Taproot tree. At the time of writing (July 2021) the Core wallet just supports single pubkey spends from the leaves of a Taproot tree. Future work on descriptors can get us to Taproot multisig (ie CHECKSIGADD) in the leaves but we'd need a Taproot upgraded Miniscript to support generic scripts (e.g. combinations of multisig and timelocks).

Without Miniscript in Core, spending from generic scripts in Taproot leaves won't be able to be supported in the Core wallet.

Moving from #17975 (comment):

I think having multiple implementations of Miniscript is good, but having multiple ones as part of this repo would only have marginal benefits, if at all. @darosior: Ohh I misunderstood. I thought you meant both Python implementations (James' existing and potentially your repo in a future PR) wouldn't be worth it. But you are thinking no Python implementation at all in this repo? Just the C++ implementation. So the functional test framework wouldn't support Miniscript and would deal entirely in script? Unit tests would be sufficient? Functional test support would be the major benefit, if that isn't needed then I agree there are only marginal benefits.

@michaelfolkson do you think this can be closed now that we have #24149 (amongst other capabilities)?

Closing for now. If there are new discussions or feature request (or ones missed here), a new issue can be created or this one reopened.