[Lightning-dev] Probing final receiver with refund timeout

Rusty Russell 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
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.


More information about the Lightning-dev mailing list