Christian et al,
I've added additional wording to the PR to explicitly state BOLT 12 MUST
NOT be used for node bootstrapping. I will squash the commits should this
proposal become a standard.
A side effect of this BOLT would be, as an example, the mobile Eclair
wallet could be updated to accept a domain parameter to specify an initial
node to open a user's first channel to rather than only the option to
"autoconnect" to their hard-coded node, and the wallet could handle
resolving and picking a node transparently, thus increasing
decentralization of "fringe" users such as mobile users and SPV nodes.
Criticism and feedback is enthusiastically invited.
Thanks,
Tyler
On Sun, Apr 8, 2018 at 5:48 PM Tyler H <tyz...@gmail.com> wrote:
> Christian,
>
> I think your points are all valid. I believe the challenge with something
> like this will be in it's general use and implementation, which is why the
> RFC doesn't make mention of intended usage past mentioning different nodes
> for "clothing" or "ebooks" a domain could advertise.
>
> --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:
>
> 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.
>
> 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.
>
> 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.
>
> --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.
>
> --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.)
>
> --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.
>
> Your pessimism is warranted and invited.
>
> Apologies for the lengthy reply,
> Tyler
>
> On Sun, Apr 8, 2018 at 4:47 PM Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> Hi Tyler,
>> Hi Robert,
>>
>> first of all, welcome to the mailing list, always good to have more
>> people looking and improving the spec. I quickly read through the spec
>> and it is very well written, and it looks good.
>>
>> On a conceptual level, I do however have some issues with the
>> proposal. I don't think that the kind of selective attachment to the
>> node of a merchant is beneficial to neither the node that is opening the
>> channel, nor for the network as a whole:
>>
>> - For the node opening a channel at the time of a payment is too late,
>> it basically means that for the first payment you'd have to wait for
>> an on-chain confirmation, even if we use `push_msat` to perform the
>> initial payment. This is bad for the user experience. Channels should
>> be opened ahead of time so that, when the customer enters a shop,
>> everything is already set up. Special cases are always hard to
>> communicate ("you have to wait, but only this time, then in future
>> all will be nice and quick")
>> - It also causes all future payments to go through that merchant, which
>> can now collate your shopping activity with all of your other
>> payments, and create a profile. It's basically the hub-and-spoke
>> threat with the added problem of the hub also knowing your identity.
>> - The merchant can cripple future payments that he might suspect are
>> going to a competitor (Starbucks may attempt to block payments for
>> amounts that look like coffee payments and go to their
>> competitor). Think net neutrality for Lightning.
>> - For the network as a whole this creates a network of large hubs that
>> are only weakly interconnected, or not connected at all, unless the
>> merchants are "generous" enough to maintain connections among each
>> other.
>>
>> But it's not all bad, I really like the possibility to look up a
>> merchant's node ID through DNS, so that my wallet can check (indirect)
>> connectivity to that node and try to optimize their connectivity.
>>
>> I think we should encourage people, and implement the clients, to open
>> random connections, biased towards strenghtening the overall
>> connectivity. With the gossip protocol we already disseminate enough
>> information to allow nodes to identify bottlenecks and provide
>> additional capacity to bridge them.
>>
>> Sorry for being so pessimistic, but I think it's important we move away
>> from people attempting to open targeted channels directly to the
>> merchants. I still regret publishing the IP address of SLEEPYARK.
>>
>> Regards,
>> Christian
>>
>> Tyler H <tyz...@gmail.com> writes:
>> > Greetings,
>> >
>> > A challenge end-users face is connecting to nodes with enough liquidity
>> to
>> > pay every merchant, and failing that, finding the merchant node in a
>> > reasonably sane way to open a channel to them for payments.
>> >
>> > As it is now, people find nodes in other people's visualizers, and pass
>> > node aliases around via word of mouth which is very prone to inaccuracy
>> and
>> > MITM attacks. A current alternative is attempting to make a payment,
>> > decoding the payment request, finding the node on your graph and
>> attempting
>> > to open a channel to the merchant. This is only possible if the
>> > destination is advertising addresses.
>> >
>> > We (Robert Olsson and I) propose an additional BOLT, tentatively
>> scheduled
>> > to be BOLT 12, to allow for operators of domain names to create SRV
>> records
>> > for their nodes. This is separate from BOLT 10's seed functionality as
>> the
>> > desired outcome is to get only the nodes associated with a particular
>> > domain. This would allow, as an example, users to say to each other
>> > "connect to a Blockstream.com node" and the user can independently look
>> up
>> > that domain, find advertised nodes and connect/open channels.
>> >
>> > This also improves security from the perspective of nodes masquerading
>> as
>> > other nodes, as anyone with a domain can authoritatively list their
>> nodes.
>> >
>> > In addition, domain operators could provide subdomains for their node
>> > addresses to distinguish between nodes intended for a specific purpose,
>> > from a human perspective.
>> >
>> > Robert Olsson (rompert) and I have created
>> > https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft
>> of
>> > what the RFC could look like.
>> >
>> > Feedback is much appreciated.
>> >
>> > Best regards,
>> > Tyler (tyzbit)
>> > _______________________________________________
>> > 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
