David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-06 📝 Original message: On Thu, Sep 05, 2019 at ...

📅 Original date posted:2019-09-06
📝 Original message:
On Thu, Sep 05, 2019 at 11:29:35AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Good morning list,
>
> I do not see much point in using miniscript for Lightning unless we
> decide to support transporting arbitrary contracts, as here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
>
> Otherwise, it would be far easier implementation-wise, to just have
> carefully-coded SCRIPT to transport HTLCs.

Something that has been impressed upon me is that using miniscript to
create optimized Bitcoin scripts is perhaps not its primary use.
Miniscript also makes it easy for any miniscript-aware wallet to figure
out how to create a valid witness for the miniscript (if the wallet has the
necessary private keys, hash pre-images, and a function to satisfy any
timelocks).

For example, right now Pieter Wuille is working on incorporating
miniscript into Bitcoin Core. If there was then a miniscript for the
current LN scripts and someone imported their keys and invoice
pre-images[1] into their Bitcoin Core wallet, then Bitcoin Core could
sign for their LN update and settlement transactions. E.g., the
C-Lightning "HSM" module could become a thin wrapper around Bitcoin
Core's wallet (or any other miniscript-aware wallet).

Later, other wallets such as hardware wallets and exchange HSMs may add
support for libminiscript, making it easy for LN nodes to delegate
signing to outside devices without anyone having to change the code of
those hard-to-change devices.

Even later than that, y'all may change the LN script either slightly or
dramatically If both the old script and the new script are miniscript
based, then maybe none of the wallets that already supported miniscript
will need to update their signing code---libminiscript will tell them
what data they need to provide for the witness and, as long as they have
functions capable of retrieving or generating that data, they'll
automatically know how to create a witness for the new miniscript.

Finally, someday consensus changes like taproot and
SIGHASH_NOINPUT/ANYPREVOUT may be activated. If libminiscript is
updated for that change, getting wallets to support those changes may be
as easy as updating their bundled libminiscript version.

In summary, miniscript does help you produce machine-optimized scripts
and analyze them (and that's a pretty nifty feature by itself), but
miniscript's true potential may come from allowing any wallet to sign for
any miniscript-compatible script, freeing developers from having to
write lots of sensitive signing code or heavily coordinating changes
across different software (as is common in LN).

-Dave

[1] I don't think this is currently possible, but adding support for it
using output script descriptors might not be difficult.