Published on: 2022-03-23T22:30:40+00:00
In an email conversation between Olaoluwa Osuntokun and Dave, the question of whether proof and verification should be strongly bound to the Lightning Network (LN) context was discussed. Currently, nodes use two bitcoin keys to construct a P2WSH multi-sig script to verify that the script matches what has been confirmed on chain. However, with taproot, the output is just a single key which raises questions about how to maintain the same level of binding. Olaoluwa suggested that nodes reconstruct the aggregated bitcoin public key to maintain this binding.Dave argued that there is a significant difference between P2WSH and P2TR in terms of maintaining binding-to-LN-usage. With P2WSH, if someone were to fake the creation of a channel by making their change outputs OP_CMS(2-of-2) with themselves, they would incur extra fee costs at spend time due to the need for more witness data over plain single-sig. However, with P2TR/MuSig2, one can make their change outputs MuSig2(2-of-2) with themselves without any additional on-chain spend costs. Therefore, Dave believes that the same level of binding cannot be maintained when P2TR keypath spends are allowed.The Lightning Network (LND) has integrated Taproot into its codebase, which is scheduled to ship in version 0.15 around April. However, since Taproot means a different on-chain funding output, the existing gossip layer needs modification because the BOLTs don't define how to validate a given output as a Taproot channel.Discussions during prior spec meetings have centered on two possible paths: 1) redesigning the channel validation portion of the gossip layer, or 2) going with a more minimal mostly the same channel_announcement-like message for Taproot channels.Laolu Osuntokun explores the second option in detail in this email. A new Taproot-aware `channel_announcement2` message could be a simple message that would include signature, length information, features, chain hash, short channel ID, node IDs, and Bitcoin keys. While adding an optional merkle proof to make channel validation more feasible for constrained/mobile clients may increase the size of the message, it may also enable more elaborate unlocking/multi-sig functionality for the normal funding output.To maintain the same level of binding for on-chain output validation, nodes would need to reconstruct the aggregated Bitcoin public key, which would ensure that there's no actual committed script root that binds the output to their context further. The `announcement_signatures` message would also need to change, as only a single signature across the wire would be sent: the musig2 partial signature. To generate these signatures, both sides would need to exchange their public nonce, which can be piggybacked on top of the existing funding message flow.Overall, Laolu Osuntokun outlines a mostly mechanical mapping of Taproot awareness to the existing gossip message flow that doesn't deviate too much from the current flow, making it easier to deploy.
Updated on: 2023-08-01T00:10:39.852741+00:00