From mats at blockchain.com Wed Mar 9 09:49:23 2016 From: mats at blockchain.com (Mats Jerratsch) Date: Wed, 9 Mar 2016 09:49:23 +0000 Subject: [Lightning-dev] Probing final receiver with refund timeout In-Reply-To: <87wppclcg8.fsf@rustcorp.com.au> References: <56D6CEA3.3020902@blockchain.com> <8737s5mfy3.fsf@rustcorp.com.au> <56DEF175.20603@blockchain.com> <87wppclcg8.fsf@rustcorp.com.au> Message-ID: <56DFF1A3.5030008@blockchain.com> > 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: