{"type":"rich","version":"1.0","title":"Bastien TEINTURIER [ARCHIVE] wrote","author_name":"Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)","author_url":"https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-02-03\n📝 Original message:\nHi ZmnSCPxj,\n\nThat is precisely what I am referring to, the lowest bits of the node ID\n\u003e are embedded in the SCID, which we do not want to openly reveal to Carol.\n\u003e\n\nGot it, I wasn't understanding your point correctly. We totally agree on\nthat.\n\nThough if the point is to prevent Carol from correlating different invoices\n\u003e as arising from the same payee, then my scheme fails against that.\n\u003e\n\nIMO we should prevent Carol from correlating different invoices by using a\ndifferent node_id for each invoice.\nThis requires minimal changes and happens entirely payee-side (see my\ninitial mail).\n\nAlice would do better to use multiple Bobs in that case.\n\u003e\n\nThat's of course a solution as well. Even with that though, if Alice opens\nmultiple channels to each of her Bobs,\nshe should use Tor and a different node_id each time for better privacy.\n\nCheers,\nBastien\n\nLe lun. 3 févr. 2020 à 15:51, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning t-bast,\n\u003e\n\u003e\n\u003e \u003e \u003e This is relevant if we ever want to hide the node id of the last node:\n\u003e Bob could provide a symmetric\n\u003e \u003e \u003e encryption key to all its peers with unpublished channels, which the\n\u003e peer can XOR with its own true\n\u003e \u003e \u003e node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.\n\u003e \u003e\n\u003e \u003e I don't understand your point here. Alice cannot hide her node_id from\n\u003e Bob since the `node_id` is\n\u003e \u003e tied to the (unannounced) channel creation.\n\u003e \u003e\n\u003e \u003e But this is not an issue. What Alice wants to break is the ability to\n\u003e link multiple HTLCs together\n\u003e \u003e because they use the same `node_id`. Since Alice can use a different\n\u003e `node_id` in every invoice,\n\u003e \u003e it's easy for her to make sure Carol cannot tie those HTLCs together.\n\u003e\n\u003e That is precisely what I am referring to, the lowest bits of the node ID\n\u003e are embedded in the SCID, which we do not want to openly reveal to Carol.\n\u003e Though if the point is to prevent Carol from correlating different\n\u003e invoices as arising from the same payee, then my scheme fails against that.\n\u003e\n\u003e \u003e\n\u003e \u003e In order to hide from Bob, the best Alice can do is use a different\n\u003e `node_id` for each channel she\n\u003e \u003e opens to Bob and use Tor. This way Bob cannot know that node_id_1 and\n\u003e node_id_2 both belong to Alice.\n\u003e \u003e I don't think we can do better than that.\n\u003e\n\u003e Alice would do better to use multiple Bobs in that case.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/acea682e/attachment-0001.html\u003e"}