Deriving channel keys deterministically from seed, musig, and channel establishment v2



Summary:

The conversation between SomberNight and ZmnSCPxj revolves around the privacy implications of deriving a static key for payment_basepoint and reusing it across multiple channels. They discuss the possibility of tweaking a unique key for each counterparty using an OP_RETURN containing the encrypted counterparty node id, but this would require a counter to avoid reuse between multiple channels with the same counterparty. The counter is problematic as users need to be able to open new channels after restoring from seed while figuring out the last value of the counter reliably. Changing the actual commitment scheme to use MuSig1/MuSig2/MuSig-DN is a lower priority than deploying PTLCs since PTLCs can be used perfectly fine with the current commitment scheme. The proposed extension should probably use different feature bits and message IDs since the current channel establishment v2 is already deployed in production on C-Lightning nodes.


Updated on: 2023-06-03T05:51:39.723376+00:00