[Lightning-dev] Probing final receiver with refund timeout
mats at blockchain.com
Tue Mar 8 15:36:21 UTC 2016
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).
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.
However, I am inclined to use those timestamps in the onion object, as
the described attackvector still exists.
Am 05/03/2016 um 09:28 schrieb Rusty Russell:
> Mats Jerratsch via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> writes:
>> Just discovered that it is possible to attack the onion routing with
>> probing too short of an absolute CLTV refund timeout.
>> When accepting a payment, one will check if the remaining timeout >
> One mitigation for this particular attack would be to remember the onion
> and always fail an identical one. That would allow a single probe,
> however (basically, "are you the final destination?").
> Also the timeout for the next hop should probably be somewhat
> randomized, at least subtracting (MIN_TIMEOUT to MIN_TIMEOUT*2).
> The question remains as to what HTLC timeout should be set to initially.
> Even if you randomize it, over time the pattern would reveal to your
> peer if you are originating all the HTLCS, for example.
Backend Engineer, Blockchain
e: mats at blockchain.com
More information about the Lightning-dev