[Lightning-dev] Probing final receiver with refund timeout

[Mats Jerratsch]

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.

Cheers



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 >
>> MIN_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.
> 
> Cheers,
> Rusty.
> 

-- 
Mats Jerratsch
Backend Engineer, Blockchain
e: mats at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA