Miniscript is a tree-based representation of Bitcoin script where every spending condition appears as a branch of a tree. So answering high-level questions like "what signers are necessary" / "what signers are sufficient", or lower level questions like "what is the maximum weight of a spend of these coins / how do I construct a witness given signatures etc", etc., suddenly become easy to answer in a very general way.
Since Miniscript can encompass all sorts of policies, from Lightning HTLCs (though unfortunately it does not support the actual script used by the deployed LN) to atomic swaps to split-custody wallets to multisignatures, it also enables the creation of general-purpose tooling that can work with all these applications, which (along with PSBT) hopefully should dramatically reduce fragmentation in the Bitcoin wallet space.
Yep - one simple reason is that Miniscript uses `OP_CSV OP_VERIFY` instead of `OP_CSV OP_DROP`; this saves us a fragment in the definition of Miniscript. Obviously if this were the only thing blocking LN-compatibility we'd just change Miniscript.
But more seriously, the existing LN HTLC switches on a pubkeyhash in a way that has no analogue in Miniscript. I don't see any way to add this to Miniscript without significantly increasing its complexity; and given that a lot of the tooling that Miniscript enables has already been implemented for the special case of Lightning, there's not a super strong benefit. (Though as somebody on lightning-dev pointed out, the ability to ask Core to sign LN transactions would be potentially very useful..)
The final result is logically equivalent to a Miniscript but the individual components are not.
Our Miniscript compiler was able to find smaller scripts equivalent to both the Lightning HTLCs without using this pubkeyhash-switch construction. I suspect, though I haven't tried, that something even more efficient could be found by combining the two approaches.
> and given that a lot of the tooling that Miniscript enables has already been implemented for the special case of Lightning, there's not a super strong benefit.
Indeed, the gap I'd worry about would more just be if the LN construct was more efficient. Sounds like it isn't, at least as a whole.
Sounds like the general mechanism miniscript doesn't have is a way to switch branches based on the 'shape' of the witness. I can see how that would be hard (impossible?) to accomplish while retaining arbitrary nestability-- it's something that would only really be simple if it were limited to being a top level construct.
> the ability to ask Core to sign LN transactions would be potentially very useful
Maybe, but to the extent that it's very useful it could just be handled as a special case.
By "shape of witness", you mean something like an or that branches based on the output of OP_DEPTH (the number of stack elements)? That is indeed something that's possible (at the top level), but I doubt it's useful in anything but exceptional cases, actually. It needs a lot of opcodes to do so, and opcodes always increase the spending cost (by growing the script), while increases to input stack only apply on the condition the respective branch is taken.
I believe that what BOLT3 received/offered HTLCs do includes two tricks we don't support in Miniscript:
* Take as input a stack element, compare its hash with a constant pkh, and if it succeeds go into a branch that uses it as a pubkey. If it fails, treat the same stack element as a hash preimage.
* Have a branch that assumes a pubkey is already on the stack, and one side uses it for CHECKSIG directly, the other side uses it as part of a CHECKMULTISIG.
I think we found a way to add the first construction to Miniscript (generically; but I don't think there is any simplicity to gain from restricting it to the top level), but it significantly increased the complexity of the language.
The second is even harder to model in the sort of structure we have. That's a limitation, but given that IIRC at the time it was at best a 1 WU gain for the BOLT scripts, and we've since improved the language in other ways, I wouldn't be surprised if it wasn't a gain at all anymore.
Adding those BOLT3 scripts as special templates in the descriptor language and signing code in Bitcoin Core wouldn't be too hard.