From ZmnSCPxj at protonmail.com  Tue Sep 21 00:59:10 2021
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Tue, 21 Sep 2021 00:59:10 +0000
Subject: [Lightning-dev] Deriving channel keys deterministically from
	seed, musig, and channel establishment v2
In-Reply-To: <JbiPFNf_HI7d8BcY1czNRQYq8rvw_WItQPRXlx06xs17mC63bkR-ZQc8MU61BxHjoMcMfYEzRD6ckNDCZjGHvuSQikcc-qiarLcB0FRuBN4=@protonmail.com>
References: <JbiPFNf_HI7d8BcY1czNRQYq8rvw_WItQPRXlx06xs17mC63bkR-ZQc8MU61BxHjoMcMfYEzRD6ckNDCZjGHvuSQikcc-qiarLcB0FRuBN4=@protonmail.com>
Message-ID: <638KqfD56MshJ6MiQmGGXlqSvEafsUahfgUtg3eBFbTjepKElOQ5bgVKR-z_fDCgyVlNKqUzdp7hR2Yx5UXY2dFWtluBX7RhkMY4sE3cVTM=@protonmail.com>

Good morning SomberNight,


> 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`).

?

Regards,
ZmnSCPxj