Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)



Summary:

In an email exchange between David A. Harding and ZmnSCPxj, the value of using miniscript for lightning scripts was discussed. While Harding initially did not see the point in using miniscript unless there were arbitrary contracts to support, ZmnSCPxj argues that incorporating miniscript into Bitcoin Core would allow any miniscript-aware wallet to figure out how to create a valid witness for the miniscript. This would enable Bitcoin Core to sign for their LN update and settlement transactions, making it easier for wallets to delegate signing to outside devices without anyone having to change the code of those hard-to-change devices. However, ZmnSCPxj mentions that there are complications involved as the signing keys involved in various Lightning scripts are derived from base keys. Thus, embedding how the derivation is done would also be required. BOLT #3 has details on this. Wallets would not only need to know the basepoint secret but also the per-commitment-point for the specific state being signed for. Despite this, ZmnSCPxj sees the value of using Miniscript for Lightning scripts. ZmnSCPxj goes on to say that while miniscript helps produce machine-optimized scripts and analyze them, its 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). Finally, he suggests that someday consensus changes like taproot and SIGHASH_NOINPUT/ANYPREVOUT may be activated, and if libminiscript is updated for that change, getting wallets to support those changes may be as easy as updating their bundled libminiscript version.


Updated on: 2023-06-02T20:11:34.645500+00:00