From ZmnSCPxj at protonmail.com Mon Sep 9 07:51:08 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 09 Sep 2019 07:51:08 +0000 Subject: [Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework) In-Reply-To: References: <20190906184305.zeulakp2ulyyjvmn@ganymede> Message-ID: Good morning all, I saw also this thread: https://www.reddit.com/r/Bitcoin/comments/d19n6l/miniscript_streamlined_bitcoin_scripting/ezjb4ec/ Regards, ZmnSCPxj > Good morning David, > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > On Saturday, September 7, 2019 2:43 AM, David A. Harding dave at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev