[Lightning-dev] Probing final receiver with refund timeout
rusty at rustcorp.com.au
Wed Mar 9 00:30:47 UTC 2016
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
> 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?
More information about the Lightning-dev