From somber.night at protonmail.com Tue Sep 21 01:36:24 2021 From: somber.night at protonmail.com (SomberNight) Date: Tue, 21 Sep 2021 01:36:24 +0000 Subject: [Lightning-dev] Deriving channel keys deterministically from seed, musig, and channel establishment v2 In-Reply-To: <638KqfD56MshJ6MiQmGGXlqSvEafsUahfgUtg3eBFbTjepKElOQ5bgVKR-z_fDCgyVlNKqUzdp7hR2Yx5UXY2dFWtluBX7RhkMY4sE3cVTM=@protonmail.com> References: <638KqfD56MshJ6MiQmGGXlqSvEafsUahfgUtg3eBFbTjepKElOQ5bgVKR-z_fDCgyVlNKqUzdp7hR2Yx5UXY2dFWtluBX7RhkMY4sE3cVTM=@protonmail.com> Message-ID: 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) Regards, SomberNight