Today we finished chapter 10 about Script, P2SH, and Miniscript.
All this said, there are some limitations when you’re using policy language or Miniscript in general.
To ensure Miniscript and its corresponding Bitcoin Script can be safely reasoned about, it does not provide access to the full power of script. Sometimes, however, doing things safely results in a script that’s unacceptably long and expensive to execute. In that case, a human may be able to construct a better solution. In regard to the example Poelstra mentioned of how transactions for the Lightning network deal with time locks, hashes, or nonces, there are some optimizations. As he put it: “Oh, you do some weird switching of the stack and you interpret things, not the way they were.” You put a public key on it, but you interpret it as a number — those kind of weird tricks.
Those might be very hard to reason about, and a human might be able to do it, but the Miniscript compiler wouldn’t, which means the compiler would end up with potentially longer Lightning scripts. Perhaps one day Miniscript can be expanded so it can also find these shortcuts. But the Miniscript developers have to be careful, because they really want to make sure there’s nothing in Miniscript that brings back the scary properties of the underlying language.
Another limitation is policy language is just one of several tools needed to make very complicated multisig wallets a practical reality. There are still questions left to answer, such as: How exactly do you do this setup? What are you emailing to each other? Are you emailing your keys or are you emailing something a little bit more abstract that you agree on first and then you exchange keys? These are practical things that aren’t solved inside a Miniscript.
At the time of writing, integrating Miniscript into the Bitcoin Core wallet is quite far along.