From rusty at rustcorp.com.au Wed Mar 9 00:30:47 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 09 Mar 2016 11:00:47 +1030 Subject: [Lightning-dev] Probing final receiver with refund timeout In-Reply-To: <56DEF175.20603@blockchain.com> References: <56D6CEA3.3020902@blockchain.com> <8737s5mfy3.fsf@rustcorp.com.au> <56DEF175.20603@blockchain.com> Message-ID: <87wppclcg8.fsf@rustcorp.com.au> Mats Jerratsch writes: > Only mitigates it such that you can't do for free, and it adds some > complexity and we might barricade some future feature with it (like > having multiple payments to one R value, over the same route). No, not filtered the same R value, filtered on the bitwise identical onion routing information (the origin would generate a fresh onion for every payment, independent of R value). The malicious node can't manipulate the routing onion, or it won't decode. (You can actually just save the authentication tag I think, for comparison). > For now I start with > > MAX_HOPS * MAX_OVERLAY * MIN_TIMEOUT > > where MAX_OVERLAY is some 'consensus' value of how much buffer time each > node should deduct from the refund time at most. That way each node can > use the full range to randomize the refund time, without running out of > time in the end. I do not see how a pattern should emerge from that though. 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. I can't come up a scheme which combats this kind of analysis, but there are cleverer people than me on this list... > 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? Thanks, Rusty.