Routing on the lightning network?



Summary:

In a discussion about the routing design of the Lightning network, CJP emphasizes the importance of privacy and enforcement of regulations. They raise concerns that certain nodes requiring identity information could cause the network to split into regulated and non-regulated parts, making it difficult for nodes to interface between the two. To counter this issue, they suggest de-coupling the function of "destination address of a route" from the function of "payer endpoint" or "payee endpoint" of a route. Rusty proposes an onion routing system where each node sees the next hop, the R hash, the amount, the timeout, and the fee being offered, but not the source or final destination. However, this requires source routing. The time-out value presents a problem in this concept as it indicates the number of hops from the payee endpoint, but if nodes are free to choose the time-out increment for themselves, they could route through a node that provides an interface to the regulated part. An additional advantage of separating destination addresses from the payment endpoints is that routing tables can be much smaller. Rusty points out that while several thousand hubs with most people as clients would work, it risks becoming centralized, leading to the problem of censorship. He suggests supporting an opaque destination token to distinguish separate payments or separate clients. Routing tables serve as a heuristic to determine how likely a payment is to succeed on one's interfaces. Fees are a real issue without source routing as the client must guess the fees. With source routing and onion, fees are known in advance, but require retransmission from the source if routes change. Rusty concludes by summarizing the benefits and drawbacks of each-hop routing and source routing.


Updated on: 2023-05-23T18:05:02.384773+00:00