{"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:\nThanks for the feedback and discussion. Here are some more comments.\n\nThis is relevant if we ever want to hide the node id of the last node: Bob\n\u003e could provide a symmetric\n\u003e encryption key to all its peers with unpublished channels, which the peer\n\u003e can XOR with its own true\n\u003e node id and use the lowest 40 bits (or 46 bits or 58 bits) in the SCID.\n\n\nI don't understand your point here. Alice cannot hide her node_id from Bob\nsince the `node_id` is\ntied to the (unannounced) channel creation.\n\nBut this is not an issue. What Alice wants to break is the ability to link\nmultiple HTLCs together\nbecause they use the same `node_id`. Since Alice can use a different\n`node_id` in every invoice,\nit's easy for her to make sure Carol cannot tie those HTLCs together.\n\nIn order to hide from Bob, the best Alice can do is use a different\n`node_id` for each channel she\nopens to Bob and use Tor. This way Bob cannot know that node_id_1 and\nnode_id_2 both belong to Alice.\nI don't think we can do better than that.\n\nI really don't want a special marker on Carol; she needs to just pay like\n\u003e normal.\n\n\nI agree that this would be the ideal outcome (and my current proposal\ndoesn't achieve that, but I'm\nhoping I can improve it to achieve that). Do note that even though my\ncurrent proposal requires\na code update from Carol, the code-change would be very small. Adding\nsupport for `payment_secret`\ndid require a change on Carol to improve security; I'm hoping that a small\nenough code-change with\na big enough privacy improvement would eventually be supported by all three\nimplementations (and\nthen find its way inside wallets).\n\nI must admit I'm a bit turned off by the state management required by your\nproposal. I'm afraid it\nmay be complex to get right, or be subject to fingerprinting and wouldn't\nresult in the privacy\ngain we're hoping.\n\nI think this really needs to be cheap for Bob; if Bob can be DoS-ed by\noffering this feature, I\ndon't think the Bobs out there will activate it.\n\nI really feel some cryptography trick can allow us to find a solution that\nrequires no more than a\nshared secret to be kept between Alice and Bob, and no\nsynchronization/state management.\nI'd like to explore this option further.\n\nCheers,\nBastien\n\nLe lun. 3 févr. 2020 à 07:51, m.a.holden via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e \u003e (I'm seeking a clever way that Bob can assign them and trivially tell\n\u003e \u003e which ID is assigned to which peer, but I can't figure it out, so I\n\u003e \u003e guess Bob keeps a mapping and restricts each peer to 256 live scids?).\n\u003e\n\u003e Hi Rusty.\n\u003e\n\u003e Here's a potential way for Alice and Bob to agree a set of 256 scids\n\u003e without any additional messages or changes to existing messages beyond a\n\u003e feature flag and a flag in open_channel, but comes with a computational\n\u003e cost.\n\u003e\n\u003e Alice and Bob agree on a random integer `r`. This could be negotiated on\n\u003e `open_channel`, but we shouldn't need to send additional information\n\u003e because we already have a random integer we can use: the\n\u003e `temporary_channel_id`. This is not known to anybody besides Alice and Bob.\n\u003e\n\u003e When a channel is locked, Bob computes n=256 scids, using something\n\u003e approximating `concat(n, trunc_bytes(sha256(ec_mult(2^n*r, Q)), 7))`, where\n\u003e `Q` is Alice's public key for the channel funding transaction.\n\u003e\n\u003e The chance of scid collisions between channels is 2^56, which is probably\n\u003e no cause for concern.\n\u003e\n\u003e Instead of keeping a map of 256 scids for each channel, Bob can use a\n\u003e cuckoo filter for efficiency. The filter can be used for a quick membership\n\u003e test and also as an associative map from scids to channels. It can also\n\u003e support scid deletion in the event of channel closure (at the cost of\n\u003e recomputing 256 ec_mults again).\n\u003e\n\u003e So when Bob receives a new HTLC to forward, he tests it against his cuckoo\n\u003e filter and retreives a candidate set of possible channels to which it may\n\u003e refer. For each channel, he takes the most significant byte of the scid as\n\u003e `m` and performs `trunc_bytes(sha256(ec_mult(2^m*r, Q)), 7)` and tests the\n\u003e least-significant 7 bytes of the result against the scid.\n\u003e\n\u003e Alice does not need to keep all of the scids she may use for invoices\n\u003e because they can be computed on the fly, but she will need to keep a copy\n\u003e of the `temporary_channel_id`.\n\u003e\n\u003e In the reverse direction of Alice forwarding HTLCs to Bob, Bob's public\n\u003e key for the funding transaction is used instead.\n\u003e\n\u003e Regards,\n\u003e Mark Holden\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/46cc458b/attachment.html\u003e"}