From dave at dtrt.org Fri Sep 6 18:43:05 2019 From: dave at dtrt.org (David A. Harding) Date: Fri, 6 Sep 2019 08:43:05 -1000 Subject: [Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework) In-Reply-To: References: Message-ID: <20190906184305.zeulakp2ulyyjvmn@ganymede> 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.