Published on: 2018-11-28T03:39:25+00:00
In a post on the Lightning-dev mailing list, Corné Plooy questions the necessity of the global/local distinction in routing, stating that current features do not seem to require it. However, Rusty suggests that while there may not be a bitmap distinction between local and global feature bits, there still exists a mental distinction. He advises users not to set compulsory feature bits in their node_announcements unless they want to stop routing. The global/local distinction in feature masks is also being discussed, with potential reasons for keeping this distinction including keeping gossip data small or for privacy reasons. However, interested parties can usually figure out local feature bits by connecting to a node, and certain features may require extra data to be gossiped. Therefore, there may not be a good reason to keep the global/local distinction.ZmnSCPxj and Olaoluwa Osuntokun discuss the nature of OG AMP payments in Lightning. ZmnSCPxj argues that OG AMP payments are spontaneous and may not require an invoice to tag a payment, while Osuntokun believes that invoices can still be used to tag payments. ZmnSCPxj suggests merging the `option_switch_ephkey` and `option_og_amp` features into `option_extra_onion_packet_types`. Rusty Russell advises the developers to edit their feature bits as appropriate before he assigns bit numbers. Another member named Laolu corrects an earlier statement that OG AMP payments cannot be accompanied by an invoice, explaining that an invoice can indeed be used with AMP to tag a payment. The use of an 8-byte identifier in the invoice can signal a service or good to be dispersed once a payment is received.A conversation between Pierre and Rusty revolves around the concept of feature masks in relation to local and global features. Rusty explains that local features only affect the protocol between direct peers, while global features can affect HTLCs and are advertised to other nodes. Pierre challenges this definition, expressing his desire to advertise his support for a local feature such as option_data_loss_protect. Rusty initially thought that local features would become ubiquitous over time, making pre-filtering unnecessary, but poses two questions: whether people want to pre-filter by local features and if only some or all local features should be made global. Pierre suggests getting rid of the global/local distinction and using node_features in the node_announcement message to describe the features that a node supports/requires.The email thread also discusses the feature masks for local and global bits in the Lightning Network. Rusty suggests promoting local bits to global bits, but if every node will eventually support a bit, it should remain local. The OG AMP feature is considered spontaneous and may not require an invoice, so it should be a global feature. There is also discussion about tying spontaneous payments to OG AMP or supporting one that is payable by base AMP or normal singlepath. Additionally, merging `option_switch_ephkey` and `option_og_amp` into `option_extra_onion_packet_types` is suggested as both require understanding extended onion packet types. The discussion aims to assign bit numbers soon and can be found on the Lightning-dev mailing list.In a recent post, Rusty Russell shares his thoughts on global vs local bit feature masks. He mentions that he has made up option names for the feature masks but has not yet assigned numbers to them. Rusty explains that local features only affect the protocol between two nodes, while global features can affect HTLCs and are advertised to other nodes. He suggests that there may be instances where one would want to promote their local bit to a global bit in order to advertise it, specifically mentioning "wumbo." However, he notes that if every node is expected to eventually support a certain bit, it should probably stay local. Rusty concludes the post by asking users to edit their bits as appropriate so that he can assign bit numbers soon. The post also includes a link to the Lightning Specification 1.1 Proposal States for those who wish to make edits.
Updated on: 2023-07-31T20:42:38.660226+00:00