From mats at blockchain.com Tue Mar 8 15:36:21 2016 From: mats at blockchain.com (Mats Jerratsch) Date: Tue, 8 Mar 2016 15:36:21 +0000 Subject: [Lightning-dev] Probing final receiver with refund timeout In-Reply-To: <8737s5mfy3.fsf@rustcorp.com.au> References: <56D6CEA3.3020902@blockchain.com> <8737s5mfy3.fsf@rustcorp.com.au> Message-ID: <56DEF175.20603@blockchain.com> 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). 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. However, I am inclined to use those timestamps in the onion object, as the described attackvector still exists. Cheers Am 05/03/2016 um 09:28 schrieb Rusty Russell: > Mats Jerratsch via Lightning-dev > <lightning-dev at lists.linuxfoundation.org> writes: >> Just discovered that it is possible to attack the onion routing with >> probing too short of an absolute CLTV refund timeout. >> >> When accepting a payment, one will check if the remaining timeout > >> MIN_TIMEOUT. > > One mitigation for this particular attack would be to remember the onion > and always fail an identical one. That would allow a single probe, > however (basically, "are you the final destination?"). > > Also the timeout for the next hop should probably be somewhat > randomized, at least subtracting (MIN_TIMEOUT to MIN_TIMEOUT*2). > > The question remains as to what HTLC timeout should be set to initially. > Even if you randomize it, over time the pattern would reveal to your > peer if you are originating all the HTLCS, for example. > > Cheers, > Rusty. > -- Mats Jerratsch Backend Engineer, Blockchain e: mats at blockchain.com PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA