Published on: 2019-08-05T10:00:04+00:00
In a conversation between fiatjaf and ZmnSCPxj, the topic of privacy erosion in routing is discussed. The use of multiple trampoline nodes in routing is explained as a way to reduce the chance of the trampoline node knowing the final payee, thus preserving privacy. This is in contrast to using just one trampoline node, which could assume the next hop is always the payee and record that information, thereby eroding privacy.The conversation then shifts to the idea of a future public network becoming too large to fit on most devices. Incentives for end-user nodes to publish their channels and store information hierarchically are discussed. ZmnSCPxj suggests implementing a global map with trampoline-payee association mappings and a detailed channel map, allowing each payer to define their own hierarchy or split. However, he also acknowledges that his ideas may be too indefinite and that the network should be allowed to evolve naturally.Trampoline routing is explained as a method of sending payments through trampoline nodes, where users defer the calculation of the route to their chosen trampoline node. For example, Alice selects T1 and RT2 as trampoline hops to send a payment to Bob. The small trampoline onion is included in the payload for T1, which then forwards the payment to RT2, who further forwards it to Bob. However, Bastien TEINTURIER points out that by not syncing the whole network, Alice has to accept being in the dark for some decisions, relying on RT2 to find a route to Bob. Despite this potential issue, trampoline routing is seen as an engineering trade-off between ease of implementation and deployment, addressing current problems and enabling future scaling.In contrast to trampoline routing, Bastien proposes the creation of a filter system similar to Bitcoin Improvement Proposal 37 (BIP37). In this system, Alice sends gossip filters to her peers and only forwards updates that match these filters. However, there is a cost for Alice in terms of opening a channel and locking funds to connect to a peer. Bastien's proposed filters are cheap to compute, either through a simple XOR or node distance comparison. More technical details can be found at [1].Bastien seeks feedback from the community on the gossip and fee estimation parts of his proposal, which can be found at https://github.com/lightningnetwork/lightning-rfc/pull/654.
Updated on: 2023-07-31T21:51:17.856936+00:00