Good morning SomberNight, > Good morning ZmnSCPxj, > > > > Solutions: > > > > > > 1. Naively, we could just derive a static key to be used as > > > payment_basepoint, reused between all our channels, and watch the > > > single resulting p2wsh script on-chain. > > > Clearly this has terrible privacy implications. > > > > > > > If the only problem is horrible privacy, and you have an > > `OP_RETURN`identifying the channel counterparty node id anyway, would it > > not be possible to tweak this for each channel? > > static_payment_basepoint_key + hash(seed | counterparty_node_id) > > This (should) result in a unique key for each counterparty, yet each > > individual counterparty cannot predict this tweak (and break your privacy > > by deriving the `static_payment_basepoint_key * G`). > > The OP_RETURN containing the encrypted counterparty node id > is only an option, ideally it should not be required. > > Also, your proposal needs a counter too, to avoid reuse between multiple > channels with the same counterparty. This counter is actually quite > problematic as users should be able to open new channels after > restoring from seed, which means they need to be able to figure out > the last value of the counter reliably, which seems potentially > problematic, so actually this might have to be a random nonce that is > wide enough to make collisions unlikely... (potentially taking up > valuable blockchain space in the OP_RETURN)
Yes, that does seem to be somewhat problematic. As to your proposal to change the open v2 protocol --- as I understand it, the current channel establishment v2 is already deployed in production on C-Lightning nodes, so at minimum your proposed extension should probably use different feature bits and message IDs, I think. CCing lisa for comment. In any case, I think changing the actual commitment scheme to use MuSig1/MuSig2/MuSig-DN is lower priority than deploying PTLCs (and PTLCs can be used perfectly fine with the current commitment scheme, since you can spend from SegWitv1 P2WPKH to P2TR perfectly fine). Though it certainly depends on others what exactly they prioritize. I estimate that by the time we get around to MuSig, we may very well already have some kind of `SIGHASH_NOINPUT` or other more complicated scheme (I hope, maybe?) and might want to switch directly to Decker-Russell-Osuntokun instead of MuSig(2/DN)-Poon-Dryja. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
