<div dir="ltr">Christian et al,<div><br></div><div>I&#39;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.</div><div><br></div><div>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&#39;s first channel to rather than only the option to &quot;autoconnect&quot; to their hard-coded node, and the wallet could handle resolving and picking a node transparently, thus increasing decentralization of &quot;fringe&quot; users such as mobile users and SPV nodes.</div><div><br></div><div>Criticism and feedback is enthusiastically invited.</div><div><br></div><div>Thanks,</div><div>Tyler</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 8, 2018 at 5:48 PM Tyler H &lt;<a href="mailto:tyzbit@gmail.com">tyzbit@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Christian,<div><br></div><div>I think your points are all valid.  I believe the challenge with something like this will be in it&#39;s general use and implementation, which is why the RFC doesn&#39;t make mention of intended usage past mentioning different nodes for &quot;clothing&quot; or &quot;ebooks&quot; a domain could advertise.</div><div><br></div><div>--Regarding looking up nodes at the time of payments: </div><div><br></div><div>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&#39;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:</div><div><br>User tries to pay lightning invoice, and it fails.  The user&#39;s wallet offers to pay via channel opening.  The user accepts.  The wallet reads the invoice for a &quot;domain&quot; 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 &quot;paid&quot; or &quot;pending X confirmations&quot; according to whatever criteria the node operator wishes to use.</div><div><br></div><div>In a simple example, you could list all of your nodes but prefer clients open channels to a single one, similar to ACINQ&#39;s setup with &quot;endurance&quot; and &quot;starblocks&quot; on testnet.  This example would simply require setting &quot;endurance&quot; 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.</div><div><br></div><div>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.  </div><div><br></div><div>There are some possible open questions regarding ensuring a payment request hasn&#39;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.<br></div><div><br></div><div>--Future payments going through the merchant:</div><div><br></div><div>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&#39;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.</div><div><br></div><div>--Merchant crippling payments:</div><div><br></div><div>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&#39;t have the appropriate channels to do so), the user&#39;s wallet will simply fall back, look up <a href="http://mcdonalds.com" target="_blank">mcdonalds.com</a>, 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&#39;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&#39;s channel, and the merchant would be sure that the payment didn&#39;t travel any further from there.)</div><div><br></div><div>--Network of large hubs:<br>I disagree.  Again, leaning on the ability to open channels with push amounts that have some minor assurances (authority of DNS records) that you&#39;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.</div><div><br></div><div>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 &quot;official&quot; nodes to ease clients, especially mobile ones, onto the network.</div><div><br></div><div>Your pessimism is warranted and invited.</div><div><br></div><div>Apologies for the lengthy reply,</div><div>Tyler</div></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 8, 2018 at 4:47 PM Christian Decker &lt;<a href="mailto:decker.christian@gmail.com" target="_blank">decker.christian@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tyler,<br>
Hi Robert,<br>
<br>
first of all, welcome to the mailing list, always good to have more<br>
people looking and improving the spec. I quickly read through the spec<br>
and it is very well written, and it looks good.<br>
<br>
On a conceptual level, I do however have some issues with the<br>
proposal. I don&#39;t think that the kind of selective attachment to the<br>
node of a merchant is beneficial to neither the node that is opening the<br>
channel, nor for the network as a whole:<br>
<br>
 - For the node opening a channel at the time of a payment is too late,<br>
   it basically means that for the first payment you&#39;d have to wait for<br>
   an on-chain confirmation, even if we use `push_msat` to perform the<br>
   initial payment. This is bad for the user experience. Channels should<br>
   be opened ahead of time so that, when the customer enters a shop,<br>
   everything is already set up. Special cases are always hard to<br>
   communicate (&quot;you have to wait, but only this time, then in future<br>
   all will be nice and quick&quot;)<br>
 - It also causes all future payments to go through that merchant, which<br>
   can now collate your shopping activity with all of your other<br>
   payments, and create a profile. It&#39;s basically the hub-and-spoke<br>
   threat with the added problem of the hub also knowing your identity.<br>
 - The merchant can cripple future payments that he might suspect are<br>
   going to a competitor (Starbucks may attempt to block payments for<br>
   amounts that look like coffee payments and go to their<br>
   competitor). Think net neutrality for Lightning.<br>
 - For the network as a whole this creates a network of large hubs that<br>
   are only weakly interconnected, or not connected at all, unless the<br>
   merchants are &quot;generous&quot; enough to maintain connections among each<br>
   other.<br>
<br>
But it&#39;s not all bad, I really like the possibility to look up a<br>
merchant&#39;s node ID through DNS, so that my wallet can check (indirect)<br>
connectivity to that node and try to optimize their connectivity.<br>
<br>
I think we should encourage people, and implement the clients, to open<br>
random connections, biased towards strenghtening the overall<br>
connectivity. With the gossip protocol we already disseminate enough<br>
information to allow nodes to identify bottlenecks and provide<br>
additional capacity to bridge them.<br>
<br>
Sorry for being so pessimistic, but I think it&#39;s important we move away<br>
from people attempting to open targeted channels directly to the<br>
merchants. I still regret publishing the IP address of SLEEPYARK.<br>
<br>
Regards,<br>
Christian<br>
<br>
Tyler H &lt;<a href="mailto:tyzbit@gmail.com" target="_blank">tyzbit@gmail.com</a>&gt; writes:<br>
&gt; Greetings,<br>
&gt;<br>
&gt; A challenge end-users face is connecting to nodes with enough liquidity to<br>
&gt; pay every merchant, and failing that, finding the merchant node in a<br>
&gt; reasonably sane way to open a channel to them for payments.<br>
&gt;<br>
&gt; As it is now, people find nodes in other people&#39;s visualizers, and pass<br>
&gt; node aliases around via word of mouth which is very prone to inaccuracy and<br>
&gt; MITM attacks. A current alternative is attempting to make a payment,<br>
&gt; decoding the payment request, finding the node on your graph and attempting<br>
&gt; to open a channel to the merchant.  This is only possible if the<br>
&gt; destination is advertising addresses.<br>
&gt;<br>
&gt; We (Robert Olsson and I) propose an additional BOLT, tentatively scheduled<br>
&gt; to be BOLT 12, to allow for operators of domain names to create SRV records<br>
&gt; for their nodes.  This is separate from BOLT 10&#39;s seed functionality as the<br>
&gt; desired outcome is to get only the nodes associated with a particular<br>
&gt; domain.  This would allow, as an example, users to say to each other<br>
&gt; &quot;connect to a Blockstream.com node&quot; and the user can independently look up<br>
&gt; that domain, find advertised nodes and connect/open channels.<br>
&gt;<br>
&gt; This also improves security from the perspective of nodes masquerading as<br>
&gt; other nodes, as anyone with a domain can authoritatively list their nodes.<br>
&gt;<br>
&gt; In addition, domain operators could provide subdomains for their node<br>
&gt; addresses to distinguish between nodes intended for a specific purpose,<br>
&gt; from a human perspective.<br>
&gt;<br>
&gt; Robert Olsson (rompert) and I have created<br>
&gt; <a href="https://github.com/lightningnetwork/lightning-rfc/pull/406" rel="noreferrer" target="_blank">https://github.com/lightningnetwork/lightning-rfc/pull/406</a> as a draft of<br>
&gt; what the RFC could look like.<br>
&gt;<br>
&gt; Feedback is much appreciated.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Tyler (tyzbit)<br>
&gt; _______________________________________________<br>
&gt; Lightning-dev mailing list<br>
&gt; <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div></blockquote></div>