Re: [Lightning-dev] Approximate assignment of option names: please fix!
Corné Plooy via Lightning-dev writes: > The only reasons I see for keeping the global/local distinction is that > you might not want to gossip everything, either to keep the gossip data > small, or for some privacy reasons. Apparently, that's all very > theoretical so far, as current features don't seem to need either. It also matters for compulsory features. As written today, if you don't understand a global feature you can't *route* through a node. If you don't understand a local feature, you can't connect to a node. So if c-lightning made option_simplfied_commitment compulsory in version 13.0 (released from the Blockstream Moon Base), we'd also be telling nodes they can't route through us, which is a lie. Perhaps we can fix this by pointing it out: that you shouldn't set compulsory feature bits in your node_announcement unless you really want to stop routing too. So we still have a mental distinction between local and global feature bits, just not a bitmap distinction? Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
The only reasons I see for keeping the global/local distinction is that you might not want to gossip everything, either to keep the gossip data small, or for some privacy reasons. Apparently, that's all very theoretical so far, as current features don't seem to need either. Ideally you'd like to have a design that requires as little consensus as possible, but for global feature bits it's clear there has to be consensus about their meaning. For a moment I thought we'd have more relaxed requirements for local feature bits (as only peers have to agree on feature bit meanings), but if we want every peer to be able to connect to every other peer, we still need global consensus on the meaning of local feature bits. I'm not even sure it makes sense to keep certain feature bits local for privacy reasons. Interested parties can usually just figure out your local feature bits by connecting to your node. As for the size of gossip data: the bits themselves shouldn't be the problem. Certain features might require extra data to be gossiped, but that should be discussed on a case-by-case data per feature. We might end up with a gossip design where you'd first receive the basic gossip data, and then try to get extended data you're interested in, based on what feature bits are enabled in the basic gossip data. So, maybe I missed something important, but no, right now I don't see a good reason for the global/local distinction. CJP On 14-11-18 00:50, Rusty Russell wrote: > Pierre writes: >> Hi Rusty, >> >>>The feature masks are split into local features (which only >>>affect the protocol between these two nodes) and global features >>>(which can affect HTLCs and are thus also advertised to other >>>nodes). >> I don't think that definition makes a lot of sense. For example I >> probably want to advertise the fact that my node supports >> option_data_loss_protect, which is a local feature. OTOH why would I >> *not* want to avertise a feature that I support? I struggle to see >> what is the point of making the distinction between local/global >> actually. > The theory was that local features concern direct peers, global features > concern others (thus *must* be advertized by gossip). > > I *expected* local features to become ubiquitous over time, so by the > time an implementation decided "I don't even want to talk to nodes > without feature X" then most nodes would support feature X, so you could > simply connect and you're probably OK. > > So the question becomes: > > 1. Do people want to pre-filter by local features? > 2. If so, only some local features, or all of them? > > If only some, then we make those ones global features. If all, then we > remove the local/global distinction altogether? > > Thanks, > Rusty. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Good morning, I believe this is simply an argument about meanings of words; to me spontaneous means that the payee does not generate a new secret to be sold as a valuable good in exchange for money, using the mechanisms for routing on Lightning. In any case, it would still be possible to perform an OG AMP payment without an invoice of any sort at all, which is the entire point of the sentence; there might not exist an invoice to put the "I support OG AMP" bit in. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, November 16, 2018 11:32 AM, Olaoluwa Osuntokun wrote: >> OG AMP is inherently spontaneous in nature, therefore invoice might not exist >> to put the feature on. > > That is incorrect. One can use an invoice along with AMP as is, in order to > tag > a payment. As an example, I want to deposit to an exhcange, so I get an > invoice > from them. I note that the invoice has a special (new) field that indicates > they accept AMP payments, and include an 8-byte identifier. Each of the > payment > shards I send over to the exchange will carry this 8-byte identifier. > Inclusion > of this identifier signals to them to credit my account with the deposit once > all the payments arrive. This generalizes to any case where a service or good > is to be dispersed once a payment is received. > > -- Laolu > > On Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev > wrote: > >> Good Morning Rusty, >> >> OG AMP is inherently spontaneous in nature, therefore invoice might not >> exist to put the feature on. >> Thus it should be global feature. >> >> Do we tie spontaneous payment to OG AMP or do we support one which is >> payable by base AMP or normal singlepath? >> >> Given that both `option_switch_ephkey` and `option_og_amp` require >> understanding extended onion packet types, would it not be better to merge >> them into `option_extra_onion_packet_types`? >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Tuesday, November 13, 2018 7:49 AM, Rusty Russell >> wrote: >> >>> Hi all, >>> >>> I went through the wiki and made up option names (not yet >>> numbers, that comes next). I re-read our description of global vs local >>> bits: >>> >>> The feature masks are split into local features (which only >>> affect the protocol between these two nodes) and global features >>> (which can affect HTLCs and are thus also advertised to other >>> nodes). >>> >>> You might want to promote your local bit to a global bit so you can >>> advertize them (wumbo?)? But if it's expected that every node will >>> eventually support a bit, then it should probably stay local. >>> >>> Please edit your bits as appropriate, so I can assign bit numbers soon: >>> >>> https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States >>> >>> Thanks! >>> Rusty. >>> >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
> OG AMP is inherently spontaneous in nature, therefore invoice might not exist > to put the feature on. That is incorrect. One can use an invoice along with AMP as is, in order to tag a payment. As an example, I want to deposit to an exhcange, so I get an invoice from them. I note that the invoice has a special (new) field that indicates they accept AMP payments, and include an 8-byte identifier. Each of the payment shards I send over to the exchange will carry this 8-byte identifier. Inclusion of this identifier signals to them to credit my account with the deposit once all the payments arrive. This generalizes to any case where a service or good is to be dispersed once a payment is received. -- Laolu On Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good Morning Rusty, > > OG AMP is inherently spontaneous in nature, therefore invoice might not > exist to put the feature on. > Thus it should be global feature. > > Do we tie spontaneous payment to OG AMP or do we support one which is > payable by base AMP or normal singlepath? > > Given that both `option_switch_ephkey` and `option_og_amp` require > understanding extended onion packet types, would it not be better to merge > them into `option_extra_onion_packet_types`? > > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, November 13, 2018 7:49 AM, Rusty Russell < > ru...@blockstream.com> wrote: > > > Hi all, > > > > I went through the wiki and made up option names (not yet > > numbers, that comes next). I re-read our description of global vs local > > bits: > > > > The feature masks are split into local features (which only > > affect the protocol between these two nodes) and global features > > (which can affect HTLCs and are thus also advertised to other > > nodes). > > > > You might want to promote your local bit to a global bit so you can > > advertize them (wumbo?)? But if it's expected that every node will > > eventually support a bit, then it should probably stay local. > > > > Please edit your bits as appropriate, so I can assign bit numbers soon: > > > > > https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States > > > > Thanks! > > Rusty. > > > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Pierre writes: > Hi Rusty, > >>The feature masks are split into local features (which only >>affect the protocol between these two nodes) and global features >>(which can affect HTLCs and are thus also advertised to other >>nodes). > > I don't think that definition makes a lot of sense. For example I > probably want to advertise the fact that my node supports > option_data_loss_protect, which is a local feature. OTOH why would I > *not* want to avertise a feature that I support? I struggle to see > what is the point of making the distinction between local/global > actually. The theory was that local features concern direct peers, global features concern others (thus *must* be advertized by gossip). I *expected* local features to become ubiquitous over time, so by the time an implementation decided "I don't even want to talk to nodes without feature X" then most nodes would support feature X, so you could simply connect and you're probably OK. So the question becomes: 1. Do people want to pre-filter by local features? 2. If so, only some local features, or all of them? If only some, then we make those ones global features. If all, then we remove the local/global distinction altogether? Thanks, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Hi Rusty, >The feature masks are split into local features (which only >affect the protocol between these two nodes) and global features >(which can affect HTLCs and are thus also advertised to other >nodes). I don't think that definition makes a lot of sense. For example I probably want to advertise the fact that my node supports option_data_loss_protect, which is a local feature. OTOH why would I *not* want to avertise a feature that I support? I struggle to see what is the point of making the distinction between local/global actually. Also, as ZmnSCPxj pointed out in his Wumbo-related post, just because I support a feature doesn't mean that I want to apply it to any peer that connects to my node. Since we can't advertise our whitelist or whatever logic we use to enable a given feature for a particular node, we can only be sure that a feature will be enabled by connecting to the peer and seeing what's in the init message. So how about just getting rid of the global/local distinction (I think this can be done in a backward-compatible way), and use the following instead: - in the node_announcement message, have a node_features that describes features my node supports/requires - in the init message, have a connection_features that are set for this particular connection. Obviously node_features/connection_features are related and must "match", in the sense that node_features constrains connection_features, particularly if we use things like option_anyone_can_wumbo (again referring to ZmnSCPxj's post). Cheers, Pierre ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Good Morning Rusty, OG AMP is inherently spontaneous in nature, therefore invoice might not exist to put the feature on. Thus it should be global feature. Do we tie spontaneous payment to OG AMP or do we support one which is payable by base AMP or normal singlepath? Given that both `option_switch_ephkey` and `option_og_amp` require understanding extended onion packet types, would it not be better to merge them into `option_extra_onion_packet_types`? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, November 13, 2018 7:49 AM, Rusty Russell wrote: > Hi all, > > I went through the wiki and made up option names (not yet > numbers, that comes next). I re-read our description of global vs local > bits: > > The feature masks are split into local features (which only > affect the protocol between these two nodes) and global features > (which can affect HTLCs and are thus also advertised to other > nodes). > > You might want to promote your local bit to a global bit so you can > advertize them (wumbo?)? But if it's expected that every node will > eventually support a bit, then it should probably stay local. > > Please edit your bits as appropriate, so I can assign bit numbers soon: > > https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States > > Thanks! > Rusty. > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Approximate assignment of option names: please fix!
Hi all, I went through the wiki and made up option names (not yet numbers, that comes next). I re-read our description of global vs local bits: The feature masks are split into local features (which only affect the protocol between these two nodes) and global features (which can affect HTLCs and are thus also advertised to other nodes). You *might* want to promote your local bit to a global bit so you can advertize them (wumbo?)? But if it's expected that every node will eventually support a bit, then it should probably stay local. Please edit your bits as appropriate, so I can assign bit numbers soon: https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
