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