DDoS on the Interledger

This gets at the question: Should the main Interledger UX use payment channels, on-ledger settlement, or hosted accounts?

What if we went with:

  • XRP: Payment channel from user to connector and on-ledger transfer from connector to user triggered either when a) the user requests it or b) when the buffered amount exceeds a connector limit
  • ETH and ERC-20: Same as XRP (as far as I can tell, the transaction cost is around $0.02 right now, which doesn’t sound too bad)
  • BTC: Lightning for both ways

Update: Lightning also has the channel lockup issue (as described by one frustrated user here) so we could also consider the same model as XRP and ETH for BTC. The fees are higher (currently around $0.50) so you would want to be a little more judicious about on-ledger transfers and setting up the payment channels. However, when you run a Lightning node, it automatically connects to multiple other nodes and pays the transaction fees for that, so opening a channel to a single Interledger connector wouldn’t be any more expensive. The confirmation time is also slower but a receiver could be configured with how many blocks it wants to wait before crediting the connector for the settlement. It could be shipped with a 6-block default but users who trust the connector a little more could configure it lower.

(Technically, we don’t need one decision on this because it is a bilateral concern but we should build the implementations with sensible defaults. The widely varying ways of using Interledger also make it difficult to explain the security model to newcomers, so it would be nice to have a recommended way of using it, even if power users and such may differ from that way.)

1 Like