[Lightning-dev] Probing final receiver with refund timeout

Mats Jerratsch mats at blockchain.com
Wed Mar 9 09:49:23 UTC 2016


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


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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/d067aae0/attachment.sig>


More information about the Lightning-dev mailing list