[Lightning-dev] Probing final receiver with refund timeout

[Rusty Russell]

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
something reasonable.

>>> 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
    http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000262.html )

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?

Rusty.