Published on: 2018-10-10T11:57:11+00:00
In a recent discussion on the Lightning-dev mailing list, there was debate about the knowledge of invoicers versus receivers in payment transactions. Pierre argued that there is no reason to believe that invoicers have more knowledge than receivers, except for the last hop. However, others disagreed and stated that receivers, who are likely running 24/7 merchant websites with up-to-date network information, have more accurate information compared to payers who are mostly mobile wallets with less reliable data. It was noted that routing table synchronization is difficult for mobile clients, making it logical for receivers to assist senders once incentives are aligned.The appropriate usage of the "r=" field in Lightning Network invoices was also discussed. Matt Corallo initially implemented it such that if an invoice had an "r=" field, any publicly discovered last-hop routes would be ignored as the "r=" data is likely more up-to-date. However, it was questioned whether it makes sense if only one or two channels are included in the "r=" field. The recommendation was to use invoice-r=-provided-hints over publicly-discovered routes but still consider other last-hops if a substantially better route is known. Rusty Russell proposed a change to c-lightning where the invoice would automatically append an 'r' field for a channel with sufficient incoming capacity, which could be useful for payment routing and establishing initial channels.Rusty Russell's proposal to automatically append an 'r' field for a channel with sufficient incoming capacity received positive feedback from the community. ACINQ mentioned having a similar idea but hadn't implemented it yet. However, there were concerns raised about leaking current channel capacity information to the user and the potential for users to track capacity over time. The lack of an "unadd" feature in the protocol means nodes must accept HTLCs before canceling them, but this can be mitigated by using the max_htlc value in the channel update.Another topic of discussion was protecting the available bandwidth in a channel. Olaoluwa Osuntokun suggested randomly rejecting packets as a way to protect against probing. However, it was noted that if a "prober" learns that a node has accepted a packet, they can determine the minimum available bandwidth. The lack of an "unadd" feature means nodes must accept HTLCs before canceling them, but dropping packets is the only recourse against an individual attempting to probe the node.Rusty Russell implemented a change to c-lightning where an 'r' field is automatically appended for a channel with sufficient incoming capacity. This feature could be useful for payment routing and establishing initial channels. However, concerns were raised about leaking channel capacity information to users and the potential for tracking capacity over time. Johan Torås Halseth suggested including all incoming channels with sufficient capacity up to a limit to address this issue. The proposal received positive feedback from the community, including ACINQ, who had a similar idea.In conclusion, the Lightning-dev mailing list discussions covered various topics such as the knowledge of invoicers versus receivers, appropriate usage of the "r=" field in invoices, and changes to c-lightning for automatic appending of an 'r' field. There were also discussions on protecting available bandwidth in a channel and potential risks related to leaking channel capacity information. Rusty Russell's proposed change received positive feedback, and the community welcomed thoughts and feedback on the discussions.
Updated on: 2023-07-31T20:28:40.329390+00:00