From info at AndySchroder.com Mon Nov 20 14:56:41 2023 From: info at AndySchroder.com (Andy Schroder) Date: Mon, 20 Nov 2023 09:56:41 -0500 Subject: [Lightning-dev] Lightning Address in a Bolt 12 world In-Reply-To: References: <409d3008-8d26-3cab-55b0-a8bfb42b6c63@AndySchroder.com> Message-ID: <94353854-994a-63c4-f8f7-f2143d281183@AndySchroder.com> > > > I agree that option 3 and 1 should be used. However, you say "clients > > (mobile wallets) would first make a DNS request corresponding to > > option 3, and if that fails, they would fallback to option 1. Domain > > owners would implement only one of those two options, depending on > > their DNS capabilities." . However, it seems to me like if we query > > for a specific user at the domain and it exists, use Option 3, but if > > it doesn't, then fall back to Option 1. So, they can actually > > implement both, depending on the user. > > Right, I meant that domain owners may choose to only implement option 1, > but if they have the capabilities to implement option 3, they can (and > probably should) also support option 1. Okay, I think it should just be clarified in the text that *both* can be used depending on the user. > > Is there a minimum path/offer expiry? Wondering if those might be way > > lower than the DNS record expiry? Seems like we want the expiry of the > > DNS record to be less than the path expiry because there will be some > > latency in propagating a record with a new blinded path or offer > > through an organization's redundant nameservers. Also, when you create > > the offer with an expiry and add it to the DNS record, that expiry is > > part of the offer data itself and relative to when it was *created*, > > but your local computer will have an expiry that starts at the time > > you *fetched* that DNS record. > > Offers can be very long-lived (months/years), especially the ones that > should be used in those scenarios. I don't think this would be an issue > at all here. True, but people don't necessarily have to use it this way. It seems to me like the client should check to see if the offer does expire before the DNS record expires and if it does, they should re-request a new record because the offer may have expired while they were fetching the first copy. > > > Will we hit any DNS record length limits with the blinded path or > > offer that need to be considered? > > That is a good question, and we should strive to use offers that are > as small as possible. In practice those will contain a 1-hop blinded > path, so they will be small enough. Also, we might want to make it explicit in the spec that you can't have duplicate records? Many DNS records allow multiple for redundancy. Is that desired here? The more records that are returned, eventually the DNS server needs to resort to TCP instead of UDP so the latency then gets higher. > > > I think you should also add an option for a type that allows different > > users to have different blinded paths. > > That can be achieved by using subdomains and sharding your users across > subdomains. This should indeed be mentioned in the future spec. I agree that subdomains can be used as a scaling feature, but an address with a subdomain in it gets longer and confusing. The scaling features need to be hidden from the user experience. Is there any problem allowing a different user to have a different blinded path? This not only helps with scalability, but say someone want's to have a domain that is shared by say 5 users, but all those users want to run their own node. If they can just manually set the 5 records and use a lightning node that doesn't need to be smart enough to speak the new lightning message that says `get_offer_from = bob at domain.com`, that is a lot simpler. > > "The statement "Note that Alice cannot verify that the offer she > > receives is really from Bob" can apply to this option too, right? > > Yes, this has the same trust-on-first-use issue. Cool, I would just add that to the text to clarify. > > > The LNURL way still relies on DNS so I'm confused why you'd want to > > add a webserver into the mix if you don't have to. > > I 100% agree with that (but not sure what you are responding to here). Was responding to Tony Giorgio comments. Andy Schroder On 11/20/23 04:40, Bastien TEINTURIER wrote: > Hi Tony, Andy, > > Matt already answered most of your questions in the previous emails. > Here are additional answers to make sure this is clear enough. > > > The interchanging between "bob" and "domain owner" is a bit confusing > > in your gist. > > I'm not sure what interchanging you're referring to. Alice is the payer, > Bob is the payment recipient and is using a `domain.com > ` address. None > of them are the domain owner in any of the examples (even though Bob > could decide to take that role). > > > Are you saying with that option, all it takes is a single DNS entry > > for "serviceprovider.com " to service > unlimited users? > > Yes, option 1 uses a single DNS record that ties a domain to a specific > lightning node. The payer then queries that lightning node to obtain an > offer from their intended recipient. > > > I agree that option 3 and 1 should be used. However, you say "clients > > (mobile wallets) would first make a DNS request corresponding to > > option 3, and if that fails, they would fallback to option 1. Domain > > owners would implement only one of those two options, depending on > > their DNS capabilities." . However, it seems to me like if we query > > for a specific user at the domain and it exists, use Option 3, but if > > it doesn't, then fall back to Option 1. So, they can actually > > implement both, depending on the user. > > Right, I meant that domain owners may choose to only implement option 1, > but if they have the capabilities to implement option 3, they can (and > probably should) also support option 1. > > > I would omit suggesting to use DoH from the spec. > > [...] > > How you query DNS seems like that should be left up to the client and > > not really part of the spec. > > That will likely just be a suggestion, not a requirement on the spec. > Note that this isn't a spec at all yet, just a design document. > > > Is there a minimum path/offer expiry? Wondering if those might be way > > lower than the DNS record expiry? Seems like we want the expiry of the > > DNS record to be less than the path expiry because there will be some > > latency in propagating a record with a new blinded path or offer > > through an organization's redundant nameservers. Also, when you create > > the offer with an expiry and add it to the DNS record, that expiry is > > part of the offer data itself and relative to when it was *created*, > > but your local computer will have an expiry that starts at the time > > you *fetched* that DNS record. > > Offers can be very long-lived (months/years), especially the ones that > should be used in those scenarios. I don't think this would be an issue > at all here. > > > Will we hit any DNS record length limits with the blinded path or > > offer that need to be considered? > > That is a good question, and we should strive to use offers that are > as small as possible. In practice those will contain a 1-hop blinded > path, so they will be small enough. > > > I think you should also add an option for a type that allows different > > users to have different blinded paths. > > That can be achieved by using subdomains and sharding your users across > subdomains. This should indeed be mentioned in the future spec. > > > I think should be revised to not use "LSP". We don't necessarily know > > if it is an LSP or a self hosted domain and node. It could be an LSP, > > but maybe not. > > Right, I tried to use "domain owner" in most places, but it's a bit > messy. I'll make the terminology clearer in the spec. > > > Seems to be a bad idea to me. You are relying on certificate > > authorities to prove the ownership of a domain? The certificate > > authorities are not an authority on domain ownership. Also, it seems > > to me like certificate authorities are a major weak link because if > > *any* certificate authority in your local trust database becomes > > faulty, *all* certificates can no longer be trusted. > > Agreed, as I mentioned in the post, I included this option to show how > we could achieve this using only lightning, but I don't think this > should be the chosen approach. > > > "The statement "Note that Alice cannot verify that the offer she > > receives is really from Bob" can apply to this option too, right? > > Yes, this has the same trust-on-first-use issue. > > > The LNURL way still relies on DNS so I'm confused why you'd want to > > add a webserver into the mix if you don't have to. > > I 100% agree with that (but not sure what you are responding to here). > > Thanks for your feedback! > Bastien > > Le?lun. 20 nov. 2023 ??09:34, Matt Corallo > a ?crit?: > > > > On 11/17/23 8:28 AM, Andy Schroder wrote: > > #Comments > > > > > > ## General > > > > - I agree that option 3 and 1 should be used. However, you say > "clients (mobile wallets) would first > > make a DNS request corresponding to option 3, and if that fails, > they would fallback to option 1. > > Domain owners would implement only one of those two options, > depending on their DNS capabilities." . > > However, it seems to me like if we query for a specific user at > the domain and it exists, use Option > > 3, but if it doesn't, then fall back to Option 1. So, they can > actually implement both, depending on > > the user. > > Yea, option 1 could reasonably take precedence, however the > tradeoff in that case would be revealing > *who* you're paying, not just which service you're paying through, > to any (honest but curious) DoH > resolver. > > > - I would omit suggesting to use DoH from the spec. DoH seems a > bit centralized to me and that's up > > to the client to decide what to do. DNS itself is a > hierarchically distributed system, so there is > > redundancy built into it (which has its flaw at the root > nameserver / ICANN level) and it seems to > > me like DoH is taking much of that distributed design away. It > seems like if you are concerned about > > your ISP snooping your traffic, you should use a tunnel so that > your traffic is obfuscated that way, > > that way things are done at the IP level and not way up at the > HTTPS level. Are you resorting to DoH > > because many ISP block traffic for DNSSEC records traffic > through their networks? Either way, how > > you query DNS seems like that should be left up to the client > and not really part of the spec. > > It is, but its worth mentioning in large part because almost > certainly ~all implementations will use > it. While I agree that it'd be very nice to not use it, in order > to do so clients would need to (a) > actually be able to query TXT records, which isn't in standard > operating system libraries, so would > probably mean DoH to 127.0.0.53 or so, (b) trust the resolver's > DNSSEC validation, which means > having some confidence its local, and not a coffee shop/etc. > > Given the level of trust you have to have here in the DNS > resolution, its almost certainly best to > cross-validate with at least multiple DoH services, unless you are > validating the DNSSEC chain > yourself (which I'd really strongly prefer as the best solution > here, but I'm unaware of any open > source code to do so). > > > - Is there a minimum path/offer expiry? Wondering if those might > be way lower than the DNS record > > expiry? Seems like we want the expiry of the DNS record to be > less than the path expiry because > > there will be some latency in propagating a record with a new > blinded path or offer through an > > organization's redundant nameservers. Also, when you create the > offer with an expiry and add it to > > the DNS record, that expiry is part of the offer data itself and > relative to when it was *created*, > > but your local computer will have an expiry that starts at the > time you *fetched* that DNS record. > > While offers can expire arbitrarily, I anticipate users of this > system will fetch long-lived offers, > eg ones that expire in a year or two. > > > - Will we hit any DNS record length limits with the blinded path > or offer that need to be considered? > > We certainly shouldn't. You can put a full PGP key in the DNS: > > $ dig > 4f31fa50e5bd5ff45684e560fc24aeee527a43739ab611c49c51098a._openpgpkey.mattcorallo.com > type61 > > > > > ## Option 1 > > > > I think you should also add an option for a type that allows > different users to have different > > blinded paths. From a scalability perspective, one may not want > to serve all users on the same node. > > Also, the user may use their own lightning node instead of the > domain operators. > > > > | hostname? ? ? ? ? ? ? ?| record type | value ? ?| TTL? ? ? ? ?| > > > |------------------------|-------------|---------------------|-------------| > > | bob._lnaddress.domain.com . | > TXT? ? ? ? ?| path: | path expiry | > > > > > > The statement > > > > "Note that Alice cannot verify that the offer she receives is > really from Bob: she has to TOFU > > (trust on first use). But that's something we fundamentally > cannot fix if the only information Alice > > has is `bob at domain.com`. However, Alice obtains a signed > statement from Bob's LSP that attests that > > `bob at domain.com` is associated with the Bolt12 offer she > receives. If she later discovers that this > > was invalid, she can publish that proof to show the world that > Bob's LSP is malicious" > > > > - I think should be revised to not use "LSP". We don't > necessarily know if it is an LSP or a self > > hosted domain and node. It could be an LSP, but maybe not. > > > > - I think we should say that we cannot verify the offer *if* Bob > does not self host and uses an LSP. > > If Bob self hosts, we know it's from Bob if DNSSEC validates and > the root nameservers and the tld > > nameservers are honest. > > > > - I think there should be a QR code format that accompanies this > so that phone apps can easily > > validate the path (or for option 3 below the offer). > > > > > > ## Option 2 > > > > > > - Seems to be a bad idea to me. You are relying on certificate > authorities to prove the ownership of > > a domain? The certificate authorities are not an authority on > domain ownership. Also, it seems to me > > like certificate authorities are a major weak link because if > *any* certificate authority in your > > local trust database becomes faulty, *all* certificates can no > longer be trusted. > > > > - This approach seems *very* unscalable because it requires the > announcements for all domains to be > > gossiped to everyone? I think that there needs to be a > decentralized DNS that is created, but this > > seems to be headed in the wrong direction. We should be able to > learn from some of the hierarchical > > features of legacy DNS and build a truly decentralized "root", > which will be more efficient. > > > > > > > > > > ## Option 3 > > > > - "The statement "Note that Alice cannot verify that the offer > she receives is really from Bob" can > > apply to this option too, right? > > > > > > Andy Schroder > > > > On 11/16/23 08:51, Bastien TEINTURIER wrote: > >> Good morning list, > >> > >> Most of you already know and love lightning addresses [1]. > >> I wanted to revisit that protocol, to see how we could improve > it and > >> fix its privacy drawbacks, while preserving the nice UX > improvements > >> that it brings. > >> > >> I have prepared a gist with three different designs that > achieve those > >> goals [2]. I'm attaching the contents of that gist below. I'd > like to > >> turn it into a bLIP once I collect enough feedback from the > community. > >> > >> I don't think we should select and implement all three options. > They > >> show that we have a large enough design space, but I think we > should > >> aim for simplicity of implementation and deployment. My > personal choice > >> would be to do options 1 and 3: clients (mobile wallets) would > first > >> make a DNS request corresponding to option 3, and if that > fails, they > >> would fallback to option 1. Domain owners would implement only > one of > >> those two options, depending on their DNS capabilities. > >> > >> Curious to hear your thoughts! > >> > >> Many thanks to Rusty and Matt who reviewed early drafts of that > gist. > >> > >> [1] https://lightningaddress.com/ > >> [2] https://gist.github.com/t-bast/78fd797a7da570d293a8663908d3339b > >> > >> # Lightning Address > >> > >> [Lightning Address](https://lightningaddress.com/) is a very > popular protocol that brings UX improvements that users love. > >> We'd like to provide those UX benefits without its privacy and > security drawbacks. > >> > >> ## Issues with the current lightning address protocol > >> > >> As described > [here](https://github.com/andrerfneves/lightning-address/blob/master/README.md), > the lightning address protocol requires payment senders to make an > HTTP request to the recipient's domain owner. > >> This has some inconvenient side effects: > >> > >> 1. The payment sender reveals their IP address to the > recipient's domain owner, who knows both the sender and the recipient. > >> 2. The domain owner can swap invoices to steal some of the payment. > >> 3. It introduces a dependency on DNS servers and the need for > an HTTP stack on the sender side. > >> > >> We can do better and fix or mitigate some of these issues, > without compromising on UX. > >> We need two somewhat distinct mechanisms: > >> > >> 1. A way to privately obtain the `node_id` associated with a > given domain. > >> 2. A way to privately contact that domain to obtain the > recipient's payment details. > >> > >> ## User story > >> > >> Alice wants to pay `bob at domain.com` without any other prior > information. > >> She doesn't want to reveal: > >> > >> * her identity to Bob (payment sender privacy) > >> * her identity to the manager of `domain.com > ? ` (payment sender privacy) > >> * the fact that she wants to pay `bob at domain.com` to her LSP > (payment recipient privacy) > >> > >> ## Option 1: use DNS records to link domains to nodes > >> > >> A first proposal would be to use a DNS record to obtain the > `node_id` associated with a given domain. > >> > >> ### Obtain a blinded path to the node associated with a domain > >> > >> Domain owners add a DNS `TXT` record for their domain > containing a blinded path to their node. > >> They may include an empty path if they wish to directly reveal > their `node_id`. > >> > >> | hostname? ? ? ? ? ? ? ?| record type | value ? ? ? ?| TTL? ? > ? ? ?| > >> > |------------------------|-------------|---------------------|-------------| > >> | _lnaddress.domain.com > . | TXT? ? ? ? ?| path: > | path expiry | > >> > >> Alice can then make a DNS query to obtain that blinded path. > >> > >> ```text > >>? ? ? Alice ? ? ? ? ? ? ? ? ? DNS server > >>? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? | dig TXT _lnaddress.domain.com > ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | > >> > |-------------------------------------------------------------------->| > >>? ? ? ? |? ? ? ? ? ? ? _lnaddress.domain.com > . IN > TXT "path:c3056fb73aa623..." | > >> > |<--------------------------------------------------------------------| > >> ``` > >> > >> :question: What encoding should we use for the blinded path > option? Bech32m with the `lnp` prefix? > >> > >> :warning: Alice should query that DNS record using > [DoH](https://datatracker.ietf.org/doc/html/rfc8484) for privacy. > >> She should also query multiple DoH servers to protect from > malicious ones. > >> > >> :warning: Alice should check the AD flag is correctly set (DNSSEC). > >> > >> ### Obtain a Bolt 12 offer from the recipient > >> > >> Now that Alice has a way to reach the node that owns Bob's > domain, she needs to contact them to obtain a Bolt 12 offer from Bob. > >> We use an `onion_message` for that, which has the following > benefits: > >> > >> * Alice doesn't reveal her identity (IP address or `node_id`) > to Bob or Bob's domain > >> * Alice doesn't reveal Bob's identity (IP address or `node_id`) > to her LSP > >> * Alice doesn't even need to know the IP address for Bob's > domain's lightning node > >> > >> ```text > >>? ? ? Alice? ? ? ? ? ? ? ? ? ? ? ? ? Alice's LSP ? ? ? ? ? ? ? ? > ? ? Bob's LSP? ? ? ? ? ? ? ? ? ? ? ? ? ? Bob > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ? ? onion_message? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |-------------------------------->| ? onion_message? ? ? > ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| get_offer_from > =bob at domain.com? ?| ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? | ?|---------------------------------->| ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ?wake_up? ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|-------------------------------->| > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? offer? ? ? ? ? ? ? | > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|<--------------------------------| > >>? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| onion_message? ? ? ? > ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? | ?|<----------------------------------| ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ? ? onion_message? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ?bob's bolt12 offer? ? ? ? | ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |? ? ? ?bob's LSP signature? ? ? ?| ? ? ? ? ? ? ? ? ? ? > ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? |<--------------------------------| ? ? ? ? ? ? ? ? ? ? > ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > >> ``` > >> > >> Note that Alice cannot verify that the offer she receives is > really from Bob: she has to TOFU (trust on first use). > >> But that's something we fundamentally cannot fix if the only > information Alice has is `bob at domain.com`. > >> However, Alice obtains a signed statement from Bob's LSP that > attests that `bob at domain.com` is associated with the Bolt12 offer > she receives. > >> If she later discovers that this was invalid, she can publish > that proof to show the world that Bob's LSP is malicious. > >> > >> Otherwise, since there needs to be some out-of-band > communication where the recipient advertizes their lightning > address (e.g. on social media), some kind of verification code > could be attached (hash of the `node_id`?). > >> The sender's wallet could optionally add a manual verification > step of that verification code. > >> This would only need to be done once, since Alice can then > reuse the same offer to fetch new invoices. > >> > >> ### Advantages and drawbacks > >> > >> The main advantage of this proposal is that it is simple, > inexpensive and relies on standard mechanisms. > >> Its drawback is that domain owners need to be able to publish > DNS `TXT` records, but that is widely supported. > >> > >> ## Option 2: use `node_announcement` to link nodes to specific > domains > >> > >> This proposal is only based on the lightning network, without > any dependency on DNS or HTTP stacks (apart from certificate > validation). > >> > >> ### Obtain the `node_id` associated with a domain > >> > >> We add fields to `node_announcement` to let nodes advertize > which domains they own. > >> Those fields would typically contain a signature of the > `node_id` using the private key for the corresponding domain TLS > certificate, along with its certificate chain. > >> Alice can then simply sync `node_announcement`s that contain > domain links with her LSP: > >> > >> ```text > >>? ? ? Alice ?LSP > >>? ? ? ? | ? | > >>? ? ? ? |? ? ? ? ? ? ? ? ? node_announcement(foobar.com > ? ) | > >> |<-----------------------------------------------| > >>? ? ? ? |? ? ? ? ? ? ? ? ? node_announcement(domain.xyz > ? ) | > >> |<-----------------------------------------------| > >>? ? ? ? | node_announcement(ln.stuff) | > >> |<-----------------------------------------------| > >>? ? ? ? | ... | > >> |<-----------------------------------------------| > >> ``` > >> > >> ### Obtain a Bolt 12 offer from the recipient > >> > >> This uses exactly the same onion message mechanism as the > previous proposal. > >> > >> ### Advantages and drawbacks > >> > >> The main advantage of this proposal is that it relies entirely > on lightning protocol messages. > >> Its drawback is that Alice needs to sync some > `node_announcement`s to obtain the domain owner's `node_id`. > >> Alice also needs to validate the certificate chain, which is > old school annoying crypto. > >> It also doesn't allow domain owners to keep their `node_id` > private (which may be useful for small community-based nodes). > >> > >> ## Option 3: use DNS records to directly store Bolt 12 offers > >> > >> Another option would be to make domain owners create one DNS > `TXT` record for each of their user, directly containing their > Bolt 12 offer: > >> > >> | hostname? ? ? ? ? ? ? ? ? ?| record type | value ? ? ? ? ? ?| > TTL? ? ? ? ? | > >> > |----------------------------|-------------|---------------------|--------------| > >> | bob._lnaddress.domain.com > . | TXT? ? ? ? ?| lno1qqx2n6mw2fh2... > | offer expiry | > >> > >> ```text > >>? ? ? Alice ? ? ? ? ? ? ? ? ? DNS server > >>? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ?| > >>? ? ? ? | dig TXT bob._lnaddress.domain.com > ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? | > >> > |-------------------------------------------------------------------->| > >>? ? ? ? |? ? ? ? ? ? ?bob._lnaddress.domain.com > . IN > TXT "lno1qqx2n6mw2fh2..." | > >> > |<--------------------------------------------------------------------| > >> ``` > >> > >> :warning: Alice should query that DNS record using > [DoH](https://datatracker.ietf.org/doc/html/rfc8484) for privacy. > >> She should also query multiple DoH servers to protect from > malicious ones. > >> > >> :warning: Alice should check the AD flag is correctly set (DNSSEC). > >> > >> ### Advantages and drawbacks > >> > >> The main advantage of this proposal is that it is > straightforward for the sender and doesn't require any addition to > the lightning protocol. > >> > >> There are some drawbacks though, mostly for the domain owner, > because they will need to create a lot of DNS records (one per user). > >> If they're using a cloud provider, there will be limitations in > the number of records they are allowed to create. > >> They may not have programmatic access to perform that operation > automatically (when a user creates their lightning address). > >> Cheers, > >> Bastien > >> > >> > >> _______________________________________________ > >> Lightning-dev mailing list > >> Lightning-dev at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: