Good morning David,

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 7, 2019 2:43 AM, David A. Harding <d...@dtrt.org> 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).

This seems an important point-of-fact.
Thank you for informing this.

It seems, there are some complications here, as the signing keys involved in 
various Lightning scripts are derived from base keys.
Thus, it seems to require also to somehow embed how the derivation is done.
BOLT #3 has detail: 
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#key-derivation
Thus the wallet not only needs to know the basepoint secret, but also the 
per-commitment-point for the specific state being signed for.

Still, it should be doable, and I now see the value of using Miniscript for 
Lightning scripts.

Regards,
ZmnSCPxj

>
> 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.


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to