Fwd: Re: Routing & Beacons



Summary:

The discussion revolves around the update of routing tables and the process and variables involved in it. The author explains that landmark nodes periodically send a message to their neighbours initiating a new temporal frame, which is then forwarded to other nodes after a delay. Once the process has completed, every node knows the best route to/from a given landmark. When a node needs to send a payment, the receiver sends her its best routes to each landmark node. Therefore the sender is able to compute the best route to reach the receiver and onion routing is possible.The author also discusses the difficulty in defining the best route due to the "base+per-satoshi" fee model and suggests a solution where a set of nominal values and the forwarding of a set of best routes (a route for each range of amounts between 2 nominal values) should be used. They also discuss the association of fees with individual payment channels, which may be useful to cope with unbalanced channels because it allows the node to signal that it's okay to receive payments on a given route but sending payments is not encouraged.The author raises the question of whether simulations would be useful and mentions the literature using the term "landmarks" instead of "beacons". The author states that they haven't decided on an update strategy for the routing tables yet, but their current idea involves prices being indicated as base + per-satoshi cost and nodes being ratelimited on their pricing updates. Furthermore, the author considers that price changes phase in over time, indicating how they change over time from some base. There's also the question of how to handle false advertising, and the author suggests broadcasting the response from a node which refuses to route your payment.


Updated on: 2023-05-23T23:36:10.675238+00:00