Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Bastien TEINTURIER]

Hi Andy,

> 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?

Agreed, this should be made explicit in the bLIP. I don't see a reason
to allow duplicate records, so we should require uniqueness.

> 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.

I'm not sure which option you're commenting on here. In option 1, you
can't have different blinded paths per user, since you have a single
DNS record that just points to the domain owner's node. In option 3,
there is already one record per user, and the user chose the blinded
path themselves. If the end user (payment recipient) wants to handle
this with their own node and control the blinded path, I think they'll
need to have their own domain and use option 3.

I may be misunderstanding your point though, let me know if that seems
to be the case.

Thanks,
Bastien

Le lun. 20 nov. 2023 à 17:32, Matt Corallo  a
écrit :

>
>
> On 11/20/23 6:53 AM, Andy Schroder wrote:
> >>
> >>> - 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).
> >
> > delv, part of bind9, does recursive DNSSEC validation locally:
> > https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html
>
> Sadly this doesn't really solve the issue. Lightning nodes need to be able
> to get a DNSSEC tree in a
> cross-platform way (which "just call delv" is not) ideally without relying
> on sending UDP directly
> at all. What this really means is that we'll eventually want to use the
> RFC 9102 CHAIN serialization
> format and put that in the node_announcement, but to do that we need some
> kind of (cross-platform
> library) client software which can take a serialized CHAIN and validate
> it. I'm unaware of any such
> software, though in theory it shouldn't be that hard to write.
>
> Matt
> ___
> 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] Lightning Address in a Bolt 12 world

[Matt Corallo]

On 11/20/23 6:53 AM, Andy Schroder wrote:


- 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). 


delv, part of bind9, does recursive DNSSEC validation locally: 
https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html


Sadly this doesn't really solve the issue. Lightning nodes need to be able to get a DNSSEC tree in a 
cross-platform way (which "just call delv" is not) ideally without relying on sending UDP directly 
at all. What this really means is that we'll eventually want to use the RFC 9102 CHAIN serialization 
format and put that in the node_announcement, but to do that we need some kind of (cross-platform 
library) client software which can take a serialized CHAIN and validate it. I'm unaware of any such 
software, though in theory it shouldn't be that hard to write.


Matt
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Andy Schroder]

> 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 = b...@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 i

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Andy Schroder]

- 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). 


delv, part of bind9, does recursive DNSSEC validation locally: 
https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html



Andy Schroder

On 11/18/23 16:27, Matt Corallo wrote:



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 ne

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Bastien TEINTURIER]

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 

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Matt Corallo]

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 `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

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Matt Corallo]

On 11/17/23 9:54 AM, Tony Giorgio via Lightning-dev wrote:

Bastien,

Maybe I'm misunderstanding option 1 or perhaps it's not clear. Are you saying with that option, all 
it takes is a single DNS entry for "serviceprovider.com" to service unlimited users? The 
interchanging between "bob" and "domain owner" is a bit confusing in your gist. I think it would be 
beneficial to make it clear what actions a service provider needs to do on behalf of their users vs 
what a user w/ a domain needs to do.


That is true for option 3. I think in practice the design that makes the most sense is both option 1 
and option 3. This allows service providers who host many users and are lazy or have some super 
restrictive DNS setup to add a single TXT record and call it a day. For those willing to run a copy 
of BIND on a server somewhere, they can avoid the extra round-trip and put a few million records in 
a zonefile no problem.


Another nice thing about the dual approach (or just option 1) is that a user using any standard 
non-custodial (or even custodial) lightning wallet that supports BOLT12 can just take their offer, 
put it in their own domain name as a single TXT record, and now they have a nice address on their 
own domain without trusting their LSP at all.


I like the idea that a semi-technical user with any domain can do this without setting up a web 
server, but I will say from my own personal dev experience, I don't know a single dev that has ever 
programmatically set up thousands to millions of DNS entries in real time. If the goal is to get 
devs to migrate from LNURL to LNDNS and to migrate from bolt11 to bolt12, I'm afraid the hurdle is 
going to get even bigger. So if I'm mistaken and option 1 just has a one-time DNS entry that service 
all users, then please let me know. I like the proposal otherwise.


I have (bitcoinheaders.net), its really incredibly easy. Almost easier than setting up a web server 
to handle lnurl. That said, I do agree with you, less because its hard, more because many 
enterprises are scared to run their own DNS infra, in part because when it fails you're totally 
hosed. For them, having option 3 support in senders would ensure its just as easy as LNURL, at least 
as long as their node software supports the relevant configuration.



Thank you,

Tony


On 11/17/23 3:08 AM, Bastien TEINTURIER wrote:

Hi Tony,

> For completeness, would you be willing to demonstrate what it might
> look like if it were bolt12 in the normal LNURL way?

Not sure that would provide "completeness", but I guess it would work
quite similarly, but instead of putting data in DNS records, that data
would be directly on files on the service provider's web server and
fetched over HTTPS, thus revealing the user's IP address and who they
want to pay.

> At scale, that would be much more difficult for LNURL service
> providers to implement for their potentially thousands to millions
> of users.

Why would that be the case? I was told handling a few million entries in
a zonefile isn't a challenge at all. And it is only necessary if the
service provider absolutely wants to only support option 3. With option
1, the service provider has a single DNS record to create. If the
service provider doesn't need to hide its node_id, the blinded path can
be empty, which guarantees that the record never expires (unless they
want to change their node_id).

On the client-side, this is very simple as well: clients should use DoH,
so they simply make HTTPS requests (no need for deep integration in the
DNS stack). Clients should first try option 3, and if that query doesn't
return a result, they fallback to option 1. This only needs to happen
once in a while, after that they can save the offer in their contact
list and reuse it until it expires, at which point they make the queries
again.

Cheers,
Bastien

Le jeu. 16 nov. 2023 à 18:52, Tony Giorgio  a écrit 
:

Bastien,

For completeness, would you be willing to demonstrate what it might look 
like if it were
bolt12 in the normal LNURL way? The concern is mostly what you brought up 
with relying on DNS
entries instead of a typical web server. At scale, that would be much more 
difficult for LNURL
service providers to implement for their potentially thousands to millions 
of users.

Something like Oblivious HTTP could be promising to remove the knowledge of 
IP for some of the
larger LNURL service providers.

Tony

On 11/16/23 7:51 AM, 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

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Andy Schroder]

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. Adding a webserver is 
increasing the latency, data transfer, and cost. There there are so many 
extra round trips required because you have multiple services and aren't 
doing everything via UDP.


DNS by design has caching and redundancy built in whereas webservers 
need to have things added into the middle to fix that. Also, you need to 
use DNSSEC and SSL in order for an HTTP based system to provide 
authentic data whereas with DNS only you only need DNSSEC.


DNS seems much more lightweight and scalable. If the DNS servers out 
there can't reliably handle millions of records then maybe a new one 
needs to be built that is optimized for this type of use case.


Just because cloud providers make it tempting to do HTTP for everything 
and not encourage you to touch the old school DNS doesn't mean we should 
build a less efficient system in my opinion. If you self host it is much 
simpler to do DNS only. Are we looking to build a cloud based network or 
self hosted one? If people really need to use only HTTP it seems to me 
like that should be done with extra layers on top of DNS where you route 
DNS over HTTP.



Andy Schroder

On 11/17/23 04:08, Bastien TEINTURIER wrote:

Hi Tony,

> For completeness, would you be willing to demonstrate what it might
> look like if it were bolt12 in the normal LNURL way?

Not sure that would provide "completeness", but I guess it would work
quite similarly, but instead of putting data in DNS records, that data
would be directly on files on the service provider's web server and
fetched over HTTPS, thus revealing the user's IP address and who they
want to pay.

> At scale, that would be much more difficult for LNURL service
> providers to implement for their potentially thousands to millions
> of users.

Why would that be the case? I was told handling a few million entries in
a zonefile isn't a challenge at all. And it is only necessary if the
service provider absolutely wants to only support option 3. With option
1, the service provider has a single DNS record to create. If the
service provider doesn't need to hide its node_id, the blinded path can
be empty, which guarantees that the record never expires (unless they
want to change their node_id).

On the client-side, this is very simple as well: clients should use DoH,
so they simply make HTTPS requests (no need for deep integration in the
DNS stack). Clients should first try option 3, and if that query doesn't
return a result, they fallback to option 1. This only needs to happen
once in a while, after that they can save the offer in their contact
list and reuse it until it expires, at which point they make the queries
again.

Cheers,
Bastien

Le jeu. 16 nov. 2023 à 18:52, Tony Giorgio 
 a écrit :


Bastien,

For completeness, would you be willing to demonstrate what it
might look like if it were bolt12 in the normal LNURL way? The
concern is mostly what you brought up with relying on DNS entries
instead of a typical web server. At scale, that would be much more
difficult for LNURL service providers to implement for their
potentially thousands to millions of users.

Something like Oblivious HTTP could be promising to remove the
knowledge of IP for some of the larger LNURL service providers.

Tony

On 11/16/23 7:51 AM, 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](

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Tony Giorgio via Lightning-dev]

Bastien,

Maybe I'm misunderstanding option 1 or perhaps it's not clear. Are you saying 
with that option, all it takes is a single DNS entry for "serviceprovider.com" 
to service unlimited users? The interchanging between "bob" and "domain owner" 
is a bit confusing in your gist. I think it would be beneficial to make it 
clear what actions a service provider needs to do on behalf of their users vs 
what a user w/ a domain needs to do.

I like the idea that a semi-technical user with any domain can do this without 
setting up a web server, but I will say from my own personal dev experience, I 
don't know a single dev that has ever programmatically set up thousands to 
millions of DNS entries in real time. If the goal is to get devs to migrate 
from LNURL to LNDNS and to migrate from bolt11 to bolt12, I'm afraid the hurdle 
is going to get even bigger. So if I'm mistaken and option 1 just has a 
one-time DNS entry that service all users, then please let me know. I like the 
proposal otherwise.

Thank you,

Tony

On 11/17/23 3:08 AM, Bastien TEINTURIER wrote:

> Hi Tony,
>
>> For completeness, would you be willing to demonstrate what it might
>> look like if it were bolt12 in the normal LNURL way?
>
> Not sure that would provide "completeness", but I guess it would work
> quite similarly, but instead of putting data in DNS records, that data
> would be directly on files on the service provider's web server and
> fetched over HTTPS, thus revealing the user's IP address and who they
> want to pay.
>
>> At scale, that would be much more difficult for LNURL service
>> providers to implement for their potentially thousands to millions
>> of users.
>
> Why would that be the case? I was told handling a few million entries in
> a zonefile isn't a challenge at all. And it is only necessary if the
> service provider absolutely wants to only support option 3. With option
> 1, the service provider has a single DNS record to create. If the
> service provider doesn't need to hide its node_id, the blinded path can
> be empty, which guarantees that the record never expires (unless they
> want to change their node_id).
>
> On the client-side, this is very simple as well: clients should use DoH,
> so they simply make HTTPS requests (no need for deep integration in the
> DNS stack). Clients should first try option 3, and if that query doesn't
> return a result, they fallback to option 1. This only needs to happen
> once in a while, after that they can save the offer in their contact
> list and reuse it until it expires, at which point they make the queries
> again.
>
> Cheers,
> Bastien
>
> Le jeu. 16 nov. 2023 à 18:52, Tony Giorgio  a 
> écrit :
>
>> Bastien,
>>
>> For completeness, would you be willing to demonstrate what it might look 
>> like if it were bolt12 in the normal LNURL way? The concern is mostly what 
>> you brought up with relying on DNS entries instead of a typical web server. 
>> At scale, that would be much more difficult for LNURL service providers to 
>> implement for their potentially thousands to millions of users.
>>
>> Something like Oblivious HTTP could be promising to remove the knowledge of 
>> IP for some of the larger LNURL service providers.
>>
>> Tony
>>
>> On 11/16/23 7:51 AM, 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

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Andy Schroder]

#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.


- 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.


- 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.


- Will we hit any DNS record length limits with the blinded path or 
offer that need to be considered?



## 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 
`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 bel

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Bastien TEINTURIER]

Hi Tony,

> For completeness, would you be willing to demonstrate what it might
> look like if it were bolt12 in the normal LNURL way?

Not sure that would provide "completeness", but I guess it would work
quite similarly, but instead of putting data in DNS records, that data
would be directly on files on the service provider's web server and
fetched over HTTPS, thus revealing the user's IP address and who they
want to pay.

> At scale, that would be much more difficult for LNURL service
> providers to implement for their potentially thousands to millions
> of users.

Why would that be the case? I was told handling a few million entries in
a zonefile isn't a challenge at all. And it is only necessary if the
service provider absolutely wants to only support option 3. With option
1, the service provider has a single DNS record to create. If the
service provider doesn't need to hide its node_id, the blinded path can
be empty, which guarantees that the record never expires (unless they
want to change their node_id).

On the client-side, this is very simple as well: clients should use DoH,
so they simply make HTTPS requests (no need for deep integration in the
DNS stack). Clients should first try option 3, and if that query doesn't
return a result, they fallback to option 1. This only needs to happen
once in a while, after that they can save the offer in their contact
list and reuse it until it expires, at which point they make the queries
again.

Cheers,
Bastien

Le jeu. 16 nov. 2023 à 18:52, Tony Giorgio  a
écrit :

> Bastien,
>
> For completeness, would you be willing to demonstrate what it might look
> like if it were bolt12 in the normal LNURL way? The concern is mostly what
> you brought up with relying on DNS entries instead of a typical web server.
> At scale, that would be much more difficult for LNURL service providers to
> implement for their potentially thousands to millions of users.
>
> Something like Oblivious HTTP could be promising to remove the knowledge
> of IP for some of the larger LNURL service providers.
>
> Tony
> On 11/16/23 7:51 AM, 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` (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 blinde

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

[Tony Giorgio via Lightning-dev]

Bastien,

For completeness, would you be willing to demonstrate what it might look like 
if it were bolt12 in the normal LNURL way? The concern is mostly what you 
brought up with relying on DNS entries instead of a typical web server. At 
scale, that would be much more difficult for LNURL service providers to 
implement for their potentially thousands to millions of users.

Something like Oblivious HTTP could be promising to remove the knowledge of IP 
for some of the larger LNURL service providers.

Tony

On 11/16/23 7:51 AM, 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
> ` (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
> . | 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