rich1.0Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://yabu.me📅 Original date posted:2020-02-03 📝 Original message: Thanks for the feedback and discussion. Here are some more comments. 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. 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. I really don't want a special marker on Carol; she needs to just pay like > normal. I agree that this would be the ideal outcome (and my current proposal doesn't achieve that, but I'm hoping I can improve it to achieve that). Do note that even though my current proposal requires a code update from Carol, the code-change would be very small. Adding support for `payment_secret` did require a change on Carol to improve security; I'm hoping that a small enough code-change with a big enough privacy improvement would eventually be supported by all three implementations (and then find its way inside wallets). I must admit I'm a bit turned off by the state management required by your proposal. I'm afraid it may be complex to get right, or be subject to fingerprinting and wouldn't result in the privacy gain we're hoping. I think this really needs to be cheap for Bob; if Bob can be DoS-ed by offering this feature, I don't think the Bobs out there will activate it. I really feel some cryptography trick can allow us to find a solution that requires no more than a shared secret to be kept between Alice and Bob, and no synchronization/state management. I'd like to explore this option further. Cheers, Bastien Le lun. 3 févr. 2020 à 07:51, m.a.holden via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a écrit : > > (I'm seeking a clever way that Bob can assign them and trivially tell > > which ID is assigned to which peer, but I can't figure it out, so I > > guess Bob keeps a mapping and restricts each peer to 256 live scids?). > > Hi Rusty. > > Here's a potential way for Alice and Bob to agree a set of 256 scids > without any additional messages or changes to existing messages beyond a > feature flag and a flag in open_channel, but comes with a computational > cost. > > Alice and Bob agree on a random integer `r`. This could be negotiated on > `open_channel`, but we shouldn't need to send additional information > because we already have a random integer we can use: the > `temporary_channel_id`. This is not known to anybody besides Alice and Bob. > > When a channel is locked, Bob computes n=256 scids, using something > approximating `concat(n, trunc_bytes(sha256(ec_mult(2^n*r, Q)), 7))`, where > `Q` is Alice's public key for the channel funding transaction. > > The chance of scid collisions between channels is 2^56, which is probably > no cause for concern. > > Instead of keeping a map of 256 scids for each channel, Bob can use a > cuckoo filter for efficiency. The filter can be used for a quick membership > test and also as an associative map from scids to channels. It can also > support scid deletion in the event of channel closure (at the cost of > recomputing 256 ec_mults again). > > So when Bob receives a new HTLC to forward, he tests it against his cuckoo > filter and retreives a candidate set of possible channels to which it may > refer. For each channel, he takes the most significant byte of the scid as > `m` and performs `trunc_bytes(sha256(ec_mult(2^m*r, Q)), 7)` and tests the > least-significant 7 bytes of the result against the scid. > > Alice does not need to keep all of the scids she may use for invoices > because they can be computed on the fly, but she will need to keep a copy > of the `temporary_channel_id`. > > In the reverse direction of Alice forwarding HTLCs to Bob, Bob's public > key for the funding transaction is used instead. > > Regards, > Mark Holden > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200203/46cc458b/attachment.html>