[Lightning-dev] Probing final receiver with refund timeout
rusty at rustcorp.com.au
Tue Mar 15 01:01:38 UTC 2016
Mats Jerratsch <mats at blockchain.com> writes:
>> 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.
> Hm, right. If all payments that come from A have a timeout larger than
> some minimum value X, he is generating all of them and is just trying to
> randomize those. However, if he creates a payment with an initial refund
> value lower than X, the payment might not succeed, because the
> intermediate nodes deducted too much.
> However, if we take into account that the amount of nodes in the route
> is not a constant, and only known to the sender, this adds another
> degree of freedom to choose the initial value.
Good point. But we still lose on the receiving side; if you ever see a
small timeout you know the next hop is the final one.
I imagine we'll be spending some time getting more sophisticated with
our value cloaking as attacks emerge, but I'm happy to start with
>>> 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?
> Not if they are randomized. The initial sender will choose a good
> starting value (see above), and deduct MIN_TIMEOUT * MIN_OVERLAY *
> RANDOM from it. Actually it doesn't provide any additional data, as that
> is the very same mechanism the intermediate hops come to that value.
OK, let me get the proposal straight:
1. Each node will publish its MIN_TIMEOUT (along
with its other info as per Option 2 in
2. The payer sums the MIN_TIMEOUT to the payee, adds some random value
(keeping it under the max value allowed by protocol) to give the
initial HTLC timeout.
3. The payer puts the 'expected_timeout' in each layer of the onion, by
subtracting the last hops' MIN_TIMEOUT from the initial timeout.
eg. Say maximum allowed timeout is 20 * 12 hours, and route is:
A (12 hours) -> B (6 hours) -> C (6 hours) -> D (4 hours)
Initial timeout has to be at least 12 + 6 + 6 + 4 == 28 hours, plus
some padding for transmission delays, say 29 hours.
It picks a random timeout between 29 and 240 hours, say now+100 hours,
and onion looks like:
[ A: now+100 [ B: now+88 [ C: now+82 [ D: now+76 ] ] ] ]
Have I missed anything?
More information about the Lightning-dev