Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-14 📝 Original message: Mats Jerratsch <mats at ...

📅 Original date posted:2016-03-14
📝 Original message:
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.