[Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[Christian Decker]

Tyler,

thanks for the detailed feedback, I'll try to address some of the issues
inline:

Tyler H <tyzbit at gmail.com> writes:
> --Regarding looking up nodes at the time of payments:
>
> In the future, nodes could negotiate a channel open with a push amount and
> provide the TXID or payment hash as proof of their payment of the invoice.
> This wouldn't even require the channel to be usable, and merchants could
> decide to accept 1 (or even 0) confirmations of this transaction based on
> their acceptable level of risk, considering the properties of the channel
> (capacity, local balance etc).  So in that use case, this would be a rough
> process of the interaction:

There is very little difference between pushing with the channel
creation and just doing an immediate update even though the channel
isn't confirmed yet. To be honest I think the `push_msat` feature is the
classical case of optimizing too early.

But the end result is still that the merchant either takes a hit in the
trustworthiness of the incoming payment, or the buyer is going to have a
bad time waiting at the checkout until the channel confirms. 

> User tries to pay lightning invoice, and it fails.  The user's wallet
> offers to pay via channel opening.  The user accepts.  The wallet reads the
> invoice for a "domain" field, or perhaps if the wallet happens to be a
> browser, it does a SRV lookup against the current domain serving the
> invoice.  The wallet looks up the domain records, and verifies the
> destination node is present.  If so, the wallet picks the correct node
> based on the records present, and opens a channel with a push amount to
> it.  The destination node sees this and via as some yet undetermined
> method, associates it to that payment invoice and chooses to mark it as
> "paid" or "pending X confirmations" according to whatever criteria the node
> operator wishes to use.

I was going to comment that, since we already have an invoice detailing
the destination, the indirection through the DNS system to find the
desired connection point was useless, but your example with Starblocks
where connections are accepted by one node, and payments by another
convinced me that this is indeed a useful feature. A feature however
that could be solved just as well by including an `r` tag in the invoice
itself. In this case you can either use the gossip protocol or the BOLT
10 DNS lookup system to locate the entry point into the merchant's
network. I don't think that a direct connection to the merchant in case
of it being unreachable is a good idea, because it creates latent
hubs. But I see the slight advantage of reducing the failure probability
w.r.t. to opening a channel with a random node.

> In a simple example, you could list all of your nodes but prefer clients
> open channels to a single one, similar to ACINQ's setup with "endurance"
> and "starblocks" on testnet.  This example would simply require setting
> "endurance" to have the highest priority. This also allows domain operators
> to have one or more public nodes, but many private ones with channels open
> to their public nodes to better manage their risk. For example, the private
> nodes could be behind a firewall.

This is definitely true, if I'm not mistaken, starblocks doesn't even
allow incoming connections, so you have to use endurance as an entry
point.

> The result of this is that the user experience is improved, and a side
> benefit is being able to safely associate a given payment request, and by
> extension node, with a domain.  Another nontrivial benefit is there will be
> more channels opened with value on the other side, allowing for receiving
> funds back from Lightning.
>
> There are some possible open questions regarding ensuring a payment request
> hasn't been spoofed, but if you present the domain to the user, he/she can
> verify that the wallet is about to open a channel to the domain they
> expect.  Other issues with this are with DNS hijacking, which to be frank
> is not an unlikely scenario.  Caution would be necessary, and perhaps
> cryptographic means of associating nodes and their associated domains would
> be a requirement for something like this to exist, but the proposed BOLT
> lays the groundwork for that to happen.

There's some value in this, that's definitely true, however these kinds
of added security through DNS haven't quite worked out in the past. Then
again we can just do the domain -> nodeid binding without encouraging
users to actually open a direct connection :-)

> --Future payments going through the merchant:
>
> This is probably the biggest wrinkle.  The merchant _does_ have the ability
> to know when a payment transits the channel, thus reducing privacy.  I
> think the proposed BOLT should only be used to improve user experience, not
> as a replacement for the decentralized nature of Lightning.  For example,
> node operators will use autopilot-like functionality for opening channels,
> BUT they will be able to augment that with looking up common stores and
> merchant's domain records and open their own channels to them to provide
> alternate routes to popular anticipated destinations for payments, thus
> making their own node more valuable and increasing the decentralization of
> the network.  For example, if you know people are going to be paying
> Starbucks, you can issue a DNS request of your own, get their current
> preferred node and connect, and then any node you have channels with will
> be able to pay Starbucks through you, without having to open a channel of
> their own.

Ok, I definitely agree that, if implemented, this would be only a
fallback solution. The problem is how to communicate this until we have
the autopilots that take care of the normal operation? The risk is that
if we spec and implement this right now, it'll become the normal mode of
operation and we'll end up with a very poor network.

> --Merchant crippling payments:
>
> With the convention I described above, using channel opens as proof of
> payment, if Starbucks wants to deny a customer the ability to pay McDonalds
> (or simply doesn't have the appropriate channels to do so), the user's
> wallet will simply fall back, look up mcdonalds.com, find the appropriate
> node and pay the invoice via channel opening.  This also partly addresses
> point 2, as if a merchant wants to spy on its customers, it must provide
> routes to its competitors.  It can either spy or deny routes, but not
> both.  In addition, the onion-like nature of payments means the merchant
> can't be sure a user paid a competitor, or a node behind them, though some
> configurations of channels and nodes can definitely reduce privacy quite a
> bit (example: a tiny etsy shop only has a couple of connections, Evil
> Starbucks being one of them with the largest channel.  A user paying an
> amount above the second largest channel to this shop would have to use the
> merchant's channel, and the merchant would be sure that the payment didn't
> travel any further from there.)

Well, the fallback solution is not exactly free either, it takes time to
confirm the channel, so the merchant can indeed force a degraded user
experience. Unlike fully random connection the merchant can also be
reasonably sure that the origin of the payment he is tampering with is
actually its customer and that degrading their experience might result
in the customer preferring them over the competition.

> --Network of large hubs:
> I disagree.  Again, leaning on the ability to open channels with push
> amounts that have some minor assurances (authority of DNS records) that
> you're getting the node you intend, I expect routing node operators to
> preemptively open channels to merchants they expect to receive payments,
> and they could advertise their own node to do so, along with allowing
> customers to connect directly to merchants.  The minimum requirement to use
> this BOLT are the same as running a Lightning node full time, plus
> ownership of a domain.
>
> With that said, I agree regarding the value of random connections in
> strengthening the network.  Nodes are well-equipped to find inefficiencies
> and correct them.  The intention of the BOLT is really to improve the
> on-boarding experience, along with providing an additional means to
> advertise "official" nodes to ease clients, especially mobile ones, onto
> the network.

I'm ok with this being a fallback solution, I just don't want it to
become the de-facto standard of operating, which'd result in the extreme
scenarios I listed above. But maybe we're both looking at this from
extreme ends and the truth (most likely) lies somewhere in-between :-)

> Your pessimism is warranted and invited.

Yeah, sorry about that, I tend to be overly pessimistic in these cases
;-)

Cheers,
Christian