[Lightning-dev] Probing final receiver with refund timeout

Mats Jerratsch mats.jerratsch at blockchain.com
Wed Mar 2 11:29:39 UTC 2016


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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160302/06cb6a52/attachment.sig>


More information about the Lightning-dev mailing list