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 <lf-li...@mattcorallo.com> 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:<blinded_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 `b...@domain.com`. However, Alice obtains a signed statement from > Bob's LSP that attests that > > `b...@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 `b...@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 <http://domain.com>` > (payment sender privacy) > >> * the fact that she wants to pay `b...@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 <http://lnaddress.domain.com>. | TXT > | path:<blinded_path> | path expiry | > >> > >> Alice can then make a DNS query to obtain that blinded path. > >> > >> ```text > >> Alice > DNS server > >> | > | > >> | dig TXT _lnaddress.domain.com <http://lnaddress.domain.com> > | > >> > |-------------------------------------------------------------------->| > >> | _lnaddress.domain.com < > http://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 = > b...@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 `b...@domain.com`. > >> However, Alice obtains a signed statement from Bob's LSP that attests > that `b...@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 < > http://foobar.com>) | > >> |<-----------------------------------------------| > >> | node_announcement(domain.xyz < > http://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 <http://lnaddress.domain.com>. | TXT > | lno1qqx2n6mw2fh2... | offer expiry | > >> > >> ```text > >> Alice > DNS server > >> | > | > >> | dig TXT bob._lnaddress.domain.com < > http://lnaddress.domain.com> | > >> > |-------------------------------------------------------------------->| > >> | bob._lnaddress.domain.com < > http://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@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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
