<div dir="ltr">I understand now, I hadn&#39;t fully considered the necessary channels for such a configuration, though there is still the value of domain owners being able to advertise preferred nodes to connect to in order to pay them efficiently.  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.<div><br></div><div>Thanks,</div><div>Tyler<br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 9, 2018 at 8:58 PM 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_-1371276572701095781protonmail_quote" type="cite"><div dir="ltr"><div><span class="m_-1371276572701095781colour" style="color:#212121">This is not the intention.  This BOLT _does not_ replace bootstrapping seed functionality, now or ever.  A client can supplement her view of the network by getting the graph from well-known nodes if she wishes, but no more.  To do otherwise _would_ centralize the network to an uncomfortable degree.  I used &quot;autoconnect&quot; because that&#39;s the terminology in the mobile wallet, but it is misleading.</span><br></div></div></blockquote><div><br></div><div>Ah, I see.  Should have been &quot;autochannel&quot; I suppose.<br></div><div><br></div><blockquote class="m_-1371276572701095781protonmail_quote" type="cite"><div dir="ltr"><div><span class="m_-1371276572701095781colour" style="color:rgb(33,33,33)"><span class="m_-1371276572701095781size" style="font-size:13px">&gt; I am not sure how the risk gets managed if the public and private nodes are owned by the same economic entity.</span></span><span class="m_-1371276572701095781colour" style="color:#212121"></span><br></div><div><span class="m_-1371276572701095781colour" style="color:rgb(33,33,33)"><span class="m_-1371276572701095781size" style="font-size:13px"></span></span><br></div><div><span class="m_-1371276572701095781colour" style="color:rgb(33,33,33)"><span class="m_-1371276572701095781size" style="font-size:13px">If the public facing node gets hacked, it cannot draw funds from the private node, only send them out to the attacker on the network, or close the channels and send the funds + wallet balance to an on-chain address.  The &quot;warm&quot; funds in your example sit on the C side of the B -&gt; C channel.</span></span><br></div></div></blockquote><div><br></div><div>Let us break this down.<br></div><div><br></div><div>Suppose we start with this state:<br></div><div><br></div><div>A 2 &lt;-&gt; 0 B 2 &lt;-&gt; 0 C<br></div><div><br></div><div>Now, again, suppose the situation is that B and C are owned by the same economic entity, Tyler &amp; Rompert Enterprises.<br></div><div><br></div><div>Suppose A pays 1 BTC to C:<br></div><div><br></div><div>A 1 &lt;-&gt; 1 B 1 &lt;-&gt; 1 C<br></div><div><br></div><div>Now suppose public node B is hacked.  This means B can close the channels and move the funds onchain to the hacker onchain address.  In that case, a total of 2 BTC can be stolen from node B.<br></div><div><br></div><div>Now suppose Tyler &amp; Rompert Enterprises decides not to actually have a private node C.  We start with this state:<br></div><div><br></div><div>A 2 &lt;-&gt; 0 B<br></div><div><br></div><div>Suppose A pays 1 BTC to B:<br></div><div><br></div><div>A 1 &lt;-&gt; 1 B<br></div><div><br></div><div>Now suppose public node B is hacked. This means B can close the channels and move the funds onchain to the hacker onchain address. In that case, a total of 1 BTC can be stolen from node B.  Compare this to the previous situation, where 2 BTC can be stolen from node B, *precisely because of the existence of B&lt;-&gt;C*.<br></div><div><br></div><div>So it is strictly better it seems, from a risk perspective, to just use a public node directly, than running a public node and one or more private nodes.  You lose less this way than also funding a channel from your public to your private node.<br></div><div><br></div><div>Either that, or you contract to an external party who takes on the risk of running a public node, most likely in exchange for much higher feerates to your private node.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></div></div>