This is a great talk from The Stanford Blockchain Conference last week on why HTLCs, which were used in past version of Interledger and are currently used in the Lightning Network aren’t always ideal.
5 Likes
Dan Robinson also had a good follow-up interview on this podcast: HTLCs (and why they suck).
The only things I’d add are:
- Even a smaller multiple on locked up capital is bad - There’s a discussion about an attacker being able to send 20 hop payments through the Lightning network and lock up 20 times the capital they put up. However, limiting the number of hops to a smaller number only helps a bit because a 5x multiplier is still very significant.
- Can you actually limit the number of hops if the packets are encrypted and onion routed? The whole idea is that you don’t know what’s in the packet, or where you are in the route. The open source software could be configured to limit the number of hops but couldn’t an attacker simply modify the software to do 20+ hops?
- Trust can’t solve the griefing problem because the attacker can send payments to themselves. In the discussion about trying to avoid receivers that hold payments. However, if you were attacking the network, you wouldn’t try to find 3rd party collaborators, you would just run multiple nodes and use them to tie up liquidity.
1 Like
Is Hyperledger’s description wrong in this instance? I thought ILP routes payments between ledgers by packetizing them not through cross chain atomic swaps?
I think that description is a bit out of date. ILPv1 did use atomic swaps but ILPv4 introduced packetization and moved towards payment channels for blockchain integrations.
1 Like