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

Tyler H tyzbit at gmail.com
Mon Apr 9 21:01:10 UTC 2018


Christian,

I hope the additional clarification in the RFC makes clear that BOLT 10
takes precedence for bootstrapping and autopilot functionality.  To
summarize the intention of this BOLT: Lightning is authoritative, but DNS
can be used to assist in on-boarding (with all of its usefulness AND
inherent flaws.)

>we can just do the domain -> nodeid binding without encouraging
> users to actually open a direct connection :-)

Right - the intention is to provide fallback mechanisms and user-friendly
ways of finding the right nodes.  If a user wants to open a channel to
Starbucks before they leave their house, then can and then let the
confirmation process start on the way there.

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

I agree, and I am in no rush to get this BOLT part of the spec before every
implementation has an autopilot function in a state they're comfortable
with.  If we want to kick it out for some months or even longer to allow
time for the network to bootstrap itself in a decentralized way, I'm fine
with that. I do think the pros of being able to associate a given
merchant/user with their incoming node in a way familiar to users will help
to ease the pain of opening channels that are useful to the user.

> 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

Ah, good point. I would exercise caution against implementing my exact
proposal regarding channel opens as payments as it was an example of
functionality that would be enabled by the BOLT that needs careful thought
and design to address concerns.  I think the ability to find nodes operated
by the owners of domains and subdomains could open up other useful
possibilities as well, including giving mobile users the option of where to
open their first channel to.

With your feedback, perhaps a good idea would be to decide on and
explicitly defined allowable uses for information gleaned from DNS records
such as the line already added about disallowing bootstrapping from a
non-seed domain.

Perhaps the first approved use-case could be invoices that include a domain
in the extra fields, clients can do a lookup on the domain and ensure the
node they're paying is listed, and if not provide a warning notification to
the user, or simply display the domain and the result of the lookup.

This would provide some protection against invoice tampering, as a
malicious actor with the ability to modify the invoice displayed to the
user would have to also display a domain other than the one the one
associated with the website the user intended to pay.

Thanks,
Tyler

On Mon, Apr 9, 2018 at 12:26 PM Christian Decker <decker.christian at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/db07c7bb/attachment-0001.html>


More information about the Lightning-dev mailing list