š
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
SomberNight [ARCHIVE] /
npub1r3ā¦f8xs3
2023-06-09 13:03:45
in reply to nevent1qā¦5ae0
Author Public Key
npub1r3wz0qhmtp77ddyvm98wpy4zsta0k5ash8ejndqjp6s8epnx5plq2f8xs3Published at
2023-06-09 13:03:45Event JSON
{
"id": "cca836b7d060acde7dfed3ea04975caeb0dc2e433e75b3f273571ad76e5541c8",
"pubkey": "1c5c2782fb587de6b48cd94ee092a282fafb53b0b9f329b4120ea07c8666a07e",
"created_at": 1686315825,
"kind": 1,
"tags": [
[
"e",
"f0c852a2a8e9cee1b342ac4cf3e92d832bafe1bf2a28075c0f9bcfbca4244b22",
"",
"root"
],
[
"e",
"c7766e29c722a5a5a510d12f576d05579a53b19f9f5f366f5566cb72493c31a3",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2021-09-20\nš Original message:\nGood morning ZmnSCPxj,\n\n\u003e \u003e Solutions:\n\u003e \u003e\n\u003e \u003e 1. Naively, we could just derive a static key to be used as\n\u003e \u003e payment_basepoint, reused between all our channels, and watch the\n\u003e \u003e single resulting p2wsh script on-chain.\n\u003e \u003e Clearly this has terrible privacy implications.\n\u003e\n\u003e 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?\n\u003e static_payment_basepoint_key + hash(seed | counterparty_node_id)\n\u003e 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`).\n\nThe OP_RETURN containing the encrypted counterparty node id\nis only an option, ideally it should not be required.\n\nAlso, your proposal needs a counter too, to avoid reuse between multiple\nchannels with the same counterparty. This counter is actually quite\nproblematic as users should be able to open new channels after\nrestoring from seed, which means they need to be able to figure out\nthe last value of the counter reliably, which seems potentially\nproblematic, so actually this might have to be a random nonce that is\nwide enough to make collisions unlikely... (potentially taking up\nvaluable blockchain space in the OP_RETURN)\n\nRegards,\nSomberNight",
"sig": "f3c4d5d613ff1e2394d42dfbe4bc5f811724347c02774d3d6d8cc526acf8a6f3a70b15667f20c27fef00197884218be855d9fa500df0850430f9f183d5d866c9"
}