From mats.jerratsch at blockchain.com Wed Mar 2 11:29:39 2016 From: mats.jerratsch at blockchain.com (Mats Jerratsch) Date: Wed, 2 Mar 2016 11:29:39 +0000 Subject: [Lightning-dev] Probing final receiver with refund timeout Message-ID: <56D6CEA3.3020902@blockchain.com> 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. When relaying the payment to the next node, one can either decide to check directly if the next node would accept it, or just relay and see what happens (the next node would then refuse to include the payment). Checking directly is equivalent of checking for 2 * MIN_TIMEOUT before accepting it. However, as the next node will check for 2 * MIN_TIMEOUT again, this is running in circles and just blindly increasing the final MIN_TIMEOUT. For an attacker it is now possible to choose a timeout that is lower than 2 * MIN_TIMEOUT. If the payment succeeds, he knows that the next node was the final receiver, if it doesn't he can redo the payment with a larger timeout without any drawback, basically probing all payments once. As discussed above, testing for a larger timeout before accepting / relaying does not solve this problem. If all nodes only accept payments with timeout > 10 * MIN_TIMEOUT, you can still probe with 10.5 * MIN_TIMEOUT. I think the only way to solve this would be to include (1) the timeout the previous node should have sent you (2) the timeout you should use for the next node into the onion object and test it accordingly. If you discover that the previous node messed with the timeout, you directly refund it. It further complicates routing though, as the source of the payment needs to know all MIN_TIMEOUT of the nodes in the route. It also needs more coordination when doing RP-routing, as the receiver has to include the timeout he chose for the first hop of his route. It probably also opens up another attack vector for attacking the network with unroutable payments. Cheers -- Mats Jerratsch Backend Engineer, Blockchain e: mats.jerratsch 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: