<div dir="ltr">Christian, ZmnSCPxj et al,<div><br></div><div>Your concerns have been taken seriously, and while this might provide some useful features with regard to opening appropriate channels (and I guess can be implemented outside of spec, if an implementation so wishes), after consideration and some very useful feedback from Olaoluwa Osuntokun on the LND slack, I&#39;ve decided to pull my support for implementing this specific proposal as part of this spec.  </div><div><br></div><div>To summarize the primary issue with this proposed BOLT: </div><div>DNS in its current form cannot be trusted as part of the Lightning spec, plain and simple.</div><div><br></div><div>While I&#39;ve rescinded my support, I don&#39;t discourage thoughtful implementation of functionality like this, but I do caution any implementation to properly inform the user as to the inherent risk in trusting DNS, and only use DNS records as a way to increase confidence, not make guarantees, that a node is associated to the domain it says it is.</div><div><br></div><div>I will continue to approach the problem of securely advertising human-understandable node names, and I hope someday soon I will have a solution Lightning can use that retains the open, decentralized properties of the technology and the underlying blockchains.</div><div><br></div><div>I leave this proposal in Robert&#39;s hands to further defend if he wishes, and I would discourage future proposals largely similar to this but on other authenticated technologies (for example, advertising node information via forum posts).  Any information that doesn&#39;t come from the network itself cannot be backed by cryptographic guarantees.</div><div><br></div><div>Other discussions regarding public vs private nodes and channel structures are encouraged.</div><div><br></div><div>Best regards,</div><div>Tyler</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 5:23 AM ZmnSCPxj &lt;<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.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>Good morning Tyler,<br></div><div> <br></div><blockquote class="m_-4618173843333333290protonmail_quote" type="cite"><div dir="ltr"><div>The external party idea is interesting, but I&#39;m fearful that it can&#39;t be done in a way that retains a bare minimum of privacy.<br></div></div></blockquote><div><br></div><div>No, of course not.  &quot;Private&quot; channels are privacy sieves and should not be used by privacy-conscious entities.  Since the channel is never published the &quot;public&quot; side knows that any economic activity going through the &quot;private&quot; channel must terminate on the other side.<br></div><div><br></div><div>Perhaps better terms would be &quot;published&quot; and &quot;unpublished&quot; channels.  We should really warn people that use of unpublished channels leaks your economic information, whereas use of published channels give the plausible deniability that it could be somebody else using that channel, not you.<br></div><div><br></div><div>You could try contracting out to multiple external parties, so that at least no single entity knows *all* your economic activity.  You still leak all your economic activity, you are simply hoping that those external parties do not pool their information together to get a complete profile of you.  Seems like a quixotic endeavor.  You may be better off using your own public node.<br></div><div><br></div><div>Multiple public nodes may be useful for load distribution.  You could also try implementation diversity, using different secure operating system, hardware, and LN node software for each node, in the hope that 0days have lower probability of affecting them all simultaneously.<br></div><div><br></div><div>You could have multiple public nodes A &lt;-&gt; B with a published channel between them that is larger than normally allowed; many of the issues with large channels disappear when you know that you can trust each other. and if you really own both A and B, then you know A can trust B and vice versa.  The purpose is load distribution: you could source half your invoices with one and half your invoices with the other, and the channel between them allows customers to use e.g. a channel to A to pay an invoice made by B when all other published channels to B are depleted.  But in terms of hackability, you should really not make A trust B and vice versa, though.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div>