Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-12 📝 Original message: On 9/12/21 7:18 PM, ...
📅 Original date posted:2021-09-12
📝 Original message:
On 9/12/21 7:18 PM, fiatjaf wrote:
> I think this is a good idea. A very simple change that can improve
> usability.
>
> Anyone can already do this today if they want, by just shoving data
> into DNS records and telling people to confirm from there, but it
> would be nice if it was standardized in a bLIP[0] just so everybody
> does it in the same way.
>
> Additionally there could be the reverse link in which nodes publish
> their domain names as their alias and that is confirmed with the DNS
> record. Then we'll finally be able to identify and trust the payee
> pubkeys in invoices!
This is kind of what I was referring to when I said "Right now, the host
names associated with LN nodes that are found using the peer to peer
gossip are more on the honor system as I understand it. If these records
existed, one could also validate the information found using the peer to
peer gossip protocol.". However, when I said "host name" I guess I was
really referring to the LN node "alias". Is there any difference in
intent between the "alias" and a host name?
Just because we verify against DNS doesn't mean we can fully trust since
DNS has centrally controlled root servers, however, it does help a lot
because they are mostly honest for right now. Assuming the root name
servers are trusted, you also need to implement DNSSEC.
With DNSSEC in mind, it may make sense for LN nodes to also advertise
"DS" records for a domain, that way the rest of the DNS records
(unrelated to LN) can be more trusted. The point here being, we can have
a two way link between DNS and LN to keep DNS in check. Basically, it's
a way for the LN node's channel capacity to give some weighting to the
authenticity of DNS. This could be a backwards compatible way to
indirectly make DNS more secure without having to store tons of data on
the blockchain because the DNS root servers will be motivated to not
publicly contradict the lightning network .... Just brainstorming here,
let me know if this makes sense..
>
> [0]: https://github.com/lightningnetwork/lightning-rfc/pull/884
>
> On Sun, Sep 12, 2021 at 8:02 PM Andy Schroder <info at andyschroder.com
> <mailto:info at andyschroder.com>> wrote:
>
> Hello,
>
> We have the <pubkey>@host format for defining a connection to a LN
> node.
>
> I'm wondering if it makes any sense to create DNS records that
> apply to LN nodes to serve this same information? For example:
>
> * example.com <http://example.com>;. IN LN ln.example.com
> <http://ln.example.com>;.
> o Allows assigning an alternate host name for the ln node
> for a domain, like an mail server has an MX record
> * example.com <http://example.com>;. IN TXT
> "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"
> o Allows storing the pubkey for the LN node in a DNS record
>
>
> If one didn't know the LN node for example.com
> <http://example.com>;, they could query the LN and TXT records and
> then find the information and make a connection using the familiar
> ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com
> <mailto:ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com> format.
> This may be of interest because if someone wants to open a channel
> in advance to a company's LN node because they know they will be
> receiving an invoice from them in the future, and they want open a
> channel directly in order to ensure a good route (and they want
> the channel to be fully confirmed/opened by the time they receive
> the invoice). This could be particularly useful when dealing with
> machines in the physical world where you want an easy way to make
> a connection and channel to with a human readable string that is
> printed on the machine, but don't even want to deal with QR codes
> or NFC (for example, your desktop computer likely doesn't have
> either of those capabilities).
>
> Right now, the host names associated with LN nodes that are found
> using the peer to peer gossip are more on the honor system as I
> understand it. If these records existed, one could also validate
> the information found using the peer to peer gossip protocol.
>
> I do realize that the DNS root servers are governed by a
> centralized entity, so this approach has it's flaws, but we could
> consider it sort of complimentary to the peer to peer gossip
> protocol. DNS does have a nice scaling property in that it is
> hierarchically distributed, so it may be more efficient long term
> than every user having a full view of the LN via the gossip
> protocol in order to find the information needed, especially when
> we can replace the DNS root servers with something that is under
> decentralized control.
>
> lnurl-rfc seems to be doing a good job at creating workflows for
> payers and payees. However, I'm not sure if a definition like I've
> suggested above fits better in lnurl-rfc or as part of a BOLT.
>
>
> Let me know of your thoughts,
>
> --
> Andy Schroder
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto: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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210912/f4bce31a/attachment-0001.html>;
📝 Original message:
On 9/12/21 7:18 PM, fiatjaf wrote:
> I think this is a good idea. A very simple change that can improve
> usability.
>
> Anyone can already do this today if they want, by just shoving data
> into DNS records and telling people to confirm from there, but it
> would be nice if it was standardized in a bLIP[0] just so everybody
> does it in the same way.
>
> Additionally there could be the reverse link in which nodes publish
> their domain names as their alias and that is confirmed with the DNS
> record. Then we'll finally be able to identify and trust the payee
> pubkeys in invoices!
This is kind of what I was referring to when I said "Right now, the host
names associated with LN nodes that are found using the peer to peer
gossip are more on the honor system as I understand it. If these records
existed, one could also validate the information found using the peer to
peer gossip protocol.". However, when I said "host name" I guess I was
really referring to the LN node "alias". Is there any difference in
intent between the "alias" and a host name?
Just because we verify against DNS doesn't mean we can fully trust since
DNS has centrally controlled root servers, however, it does help a lot
because they are mostly honest for right now. Assuming the root name
servers are trusted, you also need to implement DNSSEC.
With DNSSEC in mind, it may make sense for LN nodes to also advertise
"DS" records for a domain, that way the rest of the DNS records
(unrelated to LN) can be more trusted. The point here being, we can have
a two way link between DNS and LN to keep DNS in check. Basically, it's
a way for the LN node's channel capacity to give some weighting to the
authenticity of DNS. This could be a backwards compatible way to
indirectly make DNS more secure without having to store tons of data on
the blockchain because the DNS root servers will be motivated to not
publicly contradict the lightning network .... Just brainstorming here,
let me know if this makes sense..
>
> [0]: https://github.com/lightningnetwork/lightning-rfc/pull/884
>
> On Sun, Sep 12, 2021 at 8:02 PM Andy Schroder <info at andyschroder.com
> <mailto:info at andyschroder.com>> wrote:
>
> Hello,
>
> We have the <pubkey>@host format for defining a connection to a LN
> node.
>
> I'm wondering if it makes any sense to create DNS records that
> apply to LN nodes to serve this same information? For example:
>
> * example.com <http://example.com>;. IN LN ln.example.com
> <http://ln.example.com>;.
> o Allows assigning an alternate host name for the ln node
> for a domain, like an mail server has an MX record
> * example.com <http://example.com>;. IN TXT
> "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"
> o Allows storing the pubkey for the LN node in a DNS record
>
>
> If one didn't know the LN node for example.com
> <http://example.com>;, they could query the LN and TXT records and
> then find the information and make a connection using the familiar
> ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com
> <mailto:ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com> format.
> This may be of interest because if someone wants to open a channel
> in advance to a company's LN node because they know they will be
> receiving an invoice from them in the future, and they want open a
> channel directly in order to ensure a good route (and they want
> the channel to be fully confirmed/opened by the time they receive
> the invoice). This could be particularly useful when dealing with
> machines in the physical world where you want an easy way to make
> a connection and channel to with a human readable string that is
> printed on the machine, but don't even want to deal with QR codes
> or NFC (for example, your desktop computer likely doesn't have
> either of those capabilities).
>
> Right now, the host names associated with LN nodes that are found
> using the peer to peer gossip are more on the honor system as I
> understand it. If these records existed, one could also validate
> the information found using the peer to peer gossip protocol.
>
> I do realize that the DNS root servers are governed by a
> centralized entity, so this approach has it's flaws, but we could
> consider it sort of complimentary to the peer to peer gossip
> protocol. DNS does have a nice scaling property in that it is
> hierarchically distributed, so it may be more efficient long term
> than every user having a full view of the LN via the gossip
> protocol in order to find the information needed, especially when
> we can replace the DNS root servers with something that is under
> decentralized control.
>
> lnurl-rfc seems to be doing a good job at creating workflows for
> payers and payees. However, I'm not sure if a definition like I've
> suggested above fits better in lnurl-rfc or as part of a BOLT.
>
>
> Let me know of your thoughts,
>
> --
> Andy Schroder
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto: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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210912/f4bce31a/attachment-0001.html>;