📅 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>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 12:58:32
in reply to nevent1q…ydr4
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 12:58:32Event JSON
{
"id": "a1f4cb64d3568d3bd91a10c3ed52a5fdd5a502aef03bcae7d3967582bb934ded",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315512,
"kind": 1,
"tags": [
[
"e",
"3ed35742512a6038c8a47910d5915af4fefd8766015db6ab01e4ef19d4ac6fff",
"",
"root"
],
[
"e",
"a98ecd3b5e374e0bd7a82422f4e15c971f4a44c325f3f7be6c79270332d2990d",
"",
"reply"
],
[
"p",
"c5ac4d3e13f96dd0f580e8dfc5937824fd34336b074c3f0c28c5ca1869c68b9c"
]
],
"content": "📅 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",
"sig": "81fb21269b951c0b924f5ea1a906d42d203f026dff2f7864b05d410be10f860f6590be4fd071ca4ff55f702f0c9fb082c2ea68454e6274de651e75bdd4fdfa1d"
}