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 <tonygior...@protonmail.com> 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 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:<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
>>> |
>>>
>>> |-------------------------------------------------------------------->|
>>> | _
>>> 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
>>> ) |
>>> |<-----------------------------------------------|
>>> | 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
