Loop attack with onion routing..



Summary:

The email conversation discusses the onion routing process for payments where both sides may want to perform onion routing independently to value their privacy. The payment routing requires a separate phase before the locking of transaction funds in payer-payee direction. The email also talks about the fees charged for non-source and source routing which do not vary with time, causing a significant difference in cost vs revenue between a 30s result versus a 4-day result. The author raises a concern regarding the distribution of delayed transaction fines on a mixed source/non-source routing network. They suggest that the height of the fine should be agreed upon before performing a transaction, and an intermediate node can demand a payee-side fine that includes a weighed average of fines it has to pay payer-side on its other links to stay profitable. On the source-routed parts, the fines seem to end up with the endpoints, but there is no persistent business/trust relationship or payment channel between endpoint and intermediate source-routed node, making it difficult to enforce fine payment. Moreover, they discuss that the payee endpoint is not always the bad guy in a delayed payment scenario, and it could be that fund locking from payer to payee stopped somewhere in the middle of the route. If pre-calculated fine amounts are used, an attacker can always make a route that will result in a large loss for some intermediate nodes. The author suggests ignoring source routing for fines and distributing them as if it is only a non-source routing path. However, an attacker can create an arbitrarily long path with source routing, thereby creating arbitrarily large total damage to the network corresponding to arbitrarily large total fines.


Updated on: 2023-05-23T19:34:45.044413+00:00