📅 Original date posted:2016-03-08
📝 Original message:
Mats Jerratsch <mats at blockchain.com> writes:
> Only mitigates it such that you can't do for free, and it adds some
> complexity and we might barricade some future feature with it (like
> having multiple payments to one R value, over the same route).
No, not filtered the same R value, filtered on the bitwise identical
onion routing information (the origin would generate a fresh onion for
every payment, independent of R value). The malicious node can't
manipulate the routing onion, or it won't decode.
(You can actually just save the authentication tag I think, for
comparison).
> For now I start with
>
> MAX_HOPS * MAX_OVERLAY * MIN_TIMEOUT
>
> where MAX_OVERLAY is some 'consensus' value of how much buffer time each
> node should deduct from the refund time at most. That way each node can
> use the full range to randomize the refund time, without running out of
> time in the end. I do not see how a pattern should emerge from that though.
If A sends many HTLCs through B, B can simply plot what the timeouts
are and know that A is likely originating the HTLCs rather than relaying
them for someone else.
I can't come up a scheme which combats this kind of analysis, but there
are cleverer people than me on this list...
> However, I am inclined to use those timestamps in the onion object, as
> the described attackvector still exists.
Doesn't including timestamps in the onion provide explicit information
on the number of previous hops though?
Thanks,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:48
in reply to nevent1q…4qc0
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:48Event JSON
{
"id": "f0683c3da06495e3795f8431172fab5001a2642d8157373d49aec8913a313b02",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314748,
"kind": 1,
"tags": [
[
"e",
"5272205def020e3c5aab3c5851dc225814c5007aed79816e637c6362b3942e81",
"",
"root"
],
[
"e",
"0d43a35efdb51d7a89eccbea33782aacd0cb61e8223c0733d46815c09caf7820",
"",
"reply"
],
[
"p",
"b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528"
]
],
"content": "📅 Original date posted:2016-03-08\n📝 Original message:\nMats Jerratsch \u003cmats at blockchain.com\u003e writes:\n\u003e Only mitigates it such that you can't do for free, and it adds some\n\u003e complexity and we might barricade some future feature with it (like\n\u003e having multiple payments to one R value, over the same route).\n\nNo, not filtered the same R value, filtered on the bitwise identical\nonion routing information (the origin would generate a fresh onion for\nevery payment, independent of R value). The malicious node can't\nmanipulate the routing onion, or it won't decode.\n\n(You can actually just save the authentication tag I think, for\ncomparison).\n\n\u003e For now I start with\n\u003e\n\u003e MAX_HOPS * MAX_OVERLAY * MIN_TIMEOUT\n\u003e\n\u003e where MAX_OVERLAY is some 'consensus' value of how much buffer time each\n\u003e node should deduct from the refund time at most. That way each node can\n\u003e use the full range to randomize the refund time, without running out of\n\u003e time in the end. I do not see how a pattern should emerge from that though.\n\nIf A sends many HTLCs through B, B can simply plot what the timeouts\nare and know that A is likely originating the HTLCs rather than relaying\nthem for someone else.\n\nI can't come up a scheme which combats this kind of analysis, but there\nare cleverer people than me on this list...\n\n\u003e However, I am inclined to use those timestamps in the onion object, as\n\u003e the described attackvector still exists.\n\nDoesn't including timestamps in the onion provide explicit information\non the number of previous hops though?\n\nThanks,\nRusty.",
"sig": "e703da96a8ec29f2641603a4c579237e6c2b2592bdf478da5ad27129ba6bcb5fac0028bf38165f74fc4df9cb98e06f206a68dd780a37747c6290fab89d4d6e85"
}