Loop attack with onion routing..



Summary:

In an email conversation, Joseph Poon discusses the primary problem with "onion" routing. He explains that some parts of the graph may be faster with disclosure of R and people may have higher costs in the "time" part of "time-value". He gives an example where C, D, and E are colluding participants to each other and their R gets disclosed immediately. This way, their channel's value permits much lower fees. If they collude to be dishonest with B, B's channel is tied up for the maximum period of time. However, if they do that, C doesn't get paid until the timeout and the only way D gets paid is from C, and the only way E gets paid is from D. Therefore, he doesn't see what good colluding actually does them. Joseph suggests that C could achieve that outcome on its own just by delaying notifying B until near the timeout, no collusion necessary. In any event, if the transaction's going to succeed, the money on the B-C channel's HTLC is going to be C's, so C is mainly depriving itself by failing to communicate. If B and D collude instead, so that E reveals R to D, and D reveals R to B instead of C, then the payments could go as D pays E, D reveals R to B, A pays B, and B pays D, with the transaction from B->C and C->D remaining open until the timeout but everyone else is square. That would inconvenience C, possibly cheaply for B and D. If there's already a channel between B and D (for the "B pays D" step), he is not sure why B and D wouldn't just announce that, and once it was announced, he doesn't see why A would route via C anyway.


Updated on: 2023-05-18T00:32:29.405618+00:00