SomberNight [ARCHIVE] on Nostr: š Original date posted:2021-09-20 š Original message: Good morning ZmnSCPxj, > ...
š
Original date posted:2021-09-20
š Original message:
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
š Original message:
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