š
Original date posted:2020-02-03
š Original message:
Good morning t-bast,
> > This is relevant if we ever want to hide the node id of the last node: Bob could provide a symmetric
> > encryption key to all its peers with unpublished channels, which the peer can XOR with its own true
> > node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.
>
> I don't understand your point here. Alice cannot hide her node_id from Bob since the `node_id` is
> tied to the (unannounced) channel creation.
>
> But this is not an issue. What Alice wants to break is the ability to link multiple HTLCs together
> because they use the same `node_id`. Since Alice can use a different `node_id` in every invoice,
> it's easy for her to make sure Carol cannot tie those HTLCs together.
That is precisely what I am referring to, the lowest bits of the node ID are embedded in the SCID, which we do not want to openly reveal to Carol.
Though if the point is to prevent Carol from correlating different invoices as arising from the same payee, then my scheme fails against that.
>
> In order to hide from Bob, the best Alice can do is use a different `node_id` for each channel she
> opens to Bob and use Tor. This way Bob cannot know that node_id_1 and node_id_2 both belong to Alice.
> I don't think we can do better than that.
Alice would do better to use multiple Bobs in that case.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:58:32
in reply to nevent1qā¦0puq
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:58:32Event JSON
{
"id": "64b356eee923f8f09b8ecbb916a721b57aacd0c6458da942282fb1fad9c4ffab",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315512,
"kind": 1,
"tags": [
[
"e",
"3ed35742512a6038c8a47910d5915af4fefd8766015db6ab01e4ef19d4ac6fff",
"",
"root"
],
[
"e",
"a1f4cb64d3568d3bd91a10c3ed52a5fdd5a502aef03bcae7d3967582bb934ded",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "š
Original date posted:2020-02-03\nš Original message:\nGood morning t-bast,\n\n\n\u003e \u003e This is relevant if we ever want to hide the node id of the last node: Bob could provide a symmetric\n\u003e \u003e encryption key to all its peers with unpublished channels, which the peer can XOR with its own true\n\u003e \u003e node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.\n\u003e\n\u003e I don't understand your point here. Alice cannot hide her node_id from Bob since the `node_id` is\n\u003e tied to the (unannounced) channel creation.\n\u003e\n\u003e But this is not an issue. What Alice wants to break is the ability to link multiple HTLCs together\n\u003e because they use the same `node_id`. Since Alice can use a different `node_id` in every invoice,\n\u003e it's easy for her to make sure Carol cannot tie those HTLCs together.\n\nThat is precisely what I am referring to, the lowest bits of the node ID are embedded in the SCID, which we do not want to openly reveal to Carol.\nThough if the point is to prevent Carol from correlating different invoices as arising from the same payee, then my scheme fails against that.\n\n\u003e\n\u003e In order to hide from Bob, the best Alice can do is use a different `node_id` for each channel she\n\u003e opens to Bob and use Tor. This way Bob cannot know that node_id_1 and node_id_2 both belong to Alice.\n\u003e I don't think we can do better than that.\n\nAlice would do better to use multiple Bobs in that case.\n\n\nRegards,\nZmnSCPxj",
"sig": "642e04364092fed5c78358eb69b9389db01b591b55305679cf31d3328b77f0476a9f2b308f2dc8374ffb677f63b3c4358d42c65e9a3039ebd8ef5265d4b3cb9e"
}