Hi y'all, On the lnd side we've nearly finished fully integrating taproot into the codebase [1] (which includes the btcsuite set of libraries and also full btcwallet support), scheduled to ship in 0.15 (~April), which will enable existing users of lnd's on-chain wallet and APIs to start getting taprooty wit it. As any flavor of taproot will mean a different on-chain funding output, the _existing_ gossip layer needs some sort of modification, as the BOLTs today don't define how to validate that a given output is actually a taproot channel. Discussions during the prior spec meetings seem to have centered in on two possible paths:
1. Use this as an opportunity to entirely redesign the channel validation portion of the gossip layer (ring sigs? zkps? less validation? better privacy?). 2. Defer the above, and instead go with a more minimal mostly the same channel_announcement-like message for taproot channels. In this mail, I want to explore the second option in detail, as Rusty has already started a thread on what option #1 may look like [2]. ## A new taproot-aware `channel_announcement2` message A simple `channel_announcement2` message that was taproot aware could look something like: 1. type: xxx (`channel_announcement2`) 2. data: * [`signature`:`announcement_sig`] * [`u16`:`len`] * [`len*byte`:`features`] * [`chain_hash`:`chain_hash`] * [`short_channel_id`:`short_channel_id`] * [`point`:`node_id_1`] * [`point`:`node_id_2`] * [`point`:`bitcoin_key_1`] * [`point`:`bitcoin_key_2`] (can assume it'll be just native TLV prob also) This is pretty much the same as the _existing_ `channel_announcement` message but instead of us carrying around 4 signatures, we'd use musig2 to generate a _single_ signature under the aggregate public key (`node_id_1`+`node_id_2`+`bitcoin_key_1`+`bitcoin_key_2`). While were here, similar to what's been proposed in [2], it likely makes sense to add an optional (?) merkle proof here to make channel validation more feasible for constrained/mobile clients (they don't need to fetch all those blocks any longer). The tradeoff here is that the merkle proof would potentially be the largest part of the message, which means more on-chain data needed to store the full channel graph. Alternatively, we could make this into another gossip query option, with nodes only fetching the proofs if they actually need it (full nodes with a txindex and just fetch the transaction). ### Should the proof+verification strongly bind to the LN context? As far as on-chain output validation, the main difference would be how nodes actually validate the Bitcoin output (referenced by the `short_channel_id`) on chain. Today, nodes use the two bitcoin keys and construct a p2wsh multi-sig script and then verify that the script matches what has been confirmed on chain. With taproot, the output is actually just a single key. So if we want to maintain the same level of binding (which makes it harder to advertise fake channels using just a change output have or something), then we'd specify that nodes reconstruct the aggregated bitcoin public key (Q = a_1*B_1 + a_2*_B_2, where a_i is a blinding factor derived using the target key and every other key in the signing set) and assert that this matches the pkScript on chain. By verifying that this output key is just an aggregated key, then we can also ensure that there's no actual committed script root (a la BIP 86 [3]) which binds the output to our context further. However maybe we want to also include a `tapscript_root` field as well (so use the musig2 key as the internal key and then apply the tweaking operations and verify things match up), which would enable more elaborate unlocking/multi-sig functionality for the normal funding output. Alternatively, if we decided that this strong binding isn't as desirable (starting to get into option 1 territory), then we'd specify just a single Bitcoin key and look for that directly in the on chain script. IMO, if we're going the route of something that very closely resembles what we have today, then we shouldn't drop the strong binding, and fully verify that the key is indeed a musig2 aggregated public key. ## `announcement_signatures2` and musig2 awareness The `announcement_signatures` message would also need to change as we'd only be sending a single signature across the wire: the musig2 _partial_ signature. 1. type: xxx (`announcement_signatures2`) 2. data: * [`channel_id`:`channel_id`] * [`short_channel_id`:`short_channel_id`] * [`signature`:`partial_chan_proof_sig`] Once both sides exchange this, as normal either party can generate the `channel_announcement` message to broadcast to the network. The addition of musig2 carries with it an additional dependency: before these signatures can be generated, both sides need to exchange their public nonce (in practice it's two nonces points R_1 and R_2), which is then used to generate the aggregated nonce using for signing. Thankfully, I don't think we actually need an additional message here, and instead we can piggy back the public nonces on top of the _existing_ funding message flow. So in this case, we'd just add a `66*byte`:`public_nonce` (the public nonces use the full compressed encoding for the points, which is why it isn't jut 64 bytes) field to the open+accept channel messages, which MUST be present if the channel was to be advertised. ## Conclusion In this mail, I've sketched out a mostly mechanical mapping of taproot awareness to our existing gossip message flow. This contrasts the approach to re-design the channel advertisement as it doesn't deviate too much from the current flow (same verification with a slight twist), which may make it easier to deploy (but ofc the devil is in the details as always). Thoughts? -- Laolu [1]: https://github.com/lightningnetwork/lnd/pull/6263 [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html [3]: https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki#address-derivation
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev