<div dir="ltr"><span style="color:rgb(33,33,33);font-size:13px">&gt; Connect is not the same as make a channel with.  Connect simply lets you access gossip information.  So the hard-coded node is not privileged: it simply relays gossip information to the wallet, equivalent to getting an entire map of the network as visible from that node.  The plan is that you connect (but NOT make a channel with) a known fixed node with known high uptime, then the autopilot downloads the entire network map, then connects and creates channels to nodes from the map.</span><br><br>This is outside of the spec, isn&#39;t it? All implementations should use a seed service to bootstrap themselves to the network.<div><br></div><div>&gt; <span style="color:rgb(33,33,33);font-size:13px">The plan is that you connect (but NOT make a channel with) a known fixed node with known high uptime, then the autopilot downloads the entire network map, then connects and creates channels to nodes from the map.</span></div><div><font color="#212121"><br></font></div><div><font 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.</font></div><div><font color="#212121"><br></font></div><div><font color="#212121">I hope the additional text I&#39;ve added in the RFC makes this clear, and I regret any confusion.  Most of the functionality enabled by this proposed BOLT would be in giving users the ability to more easily open channels to the node they intend to, by giving node operators a way to advertise their nodes. I do think perhaps the proposed RFC could be further improved by adding a stipulation that autopilot functionality MUST NOT rely on domains advertising nodes, and a user MUST choose to open a channel to a node based on the domain.</font></div><div><font color="#212121"><br></font></div><div><span style="color:rgb(33,33,33);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><font color="#212121"><br></font></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><span style="color:rgb(33,33,33);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></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div><font color="#212121">Regarding &quot;hubs&quot;, I think that while the barrier to entry into running multiple nodes isn&#39;t zero, it&#39;s low enough that even singular moderately technical node operators might operate with their channels in such a configuration as this to better reduce their external risk.  A user with a laptop and Docker could run multiple nodes with channels between them, for instance, and the containers could be insulated from each other except for Lightning protocol traffic.</font></div><div><br></div><div>Best,</div><div>Tyler</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 9, 2018 at 7:31 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><div>&gt; 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.<br></div><div><br></div><div>Connect is not the same as make a channel with.  Connect simply lets you access gossip information.  So the hard-coded node is not privileged: it simply relays gossip information to the wallet, equivalent to getting an entire map of the network as visible from that node.  The plan is that you connect (but NOT make a channel with) a known fixed node with known high uptime, then the autopilot downloads the entire network map, then connects and creates channels to nodes from the map.<br></div><div><br></div><div>While certainly getting a node other than the hardcoded one might let you avoid censorship of nodes by free software developers of the wallet, I am uncertain if getting gossip from a known merchant node is *better* than that.  Certainly you can be sure that the free software developers have at least some nominal checks and balances (and publicly-visible codebase) to prevent censorship, which might not be the case for purely commercial enterprises.<br></div><div><br></div><div>&gt; 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.<br></div><div><br></div><div>I am not sure how the risk gets managed if the public and private nodes are owned by the same economic entity.<br></div><div><br></div><div>Suppose I am a single economic entity, and I have a public node B and a private node C.  You are the customer A who pays me.<br></div><div><br></div><div>A -&gt; B -&gt; C<br></div><div><br></div><div>Now the channel B-&gt;C contains money I own.  Any transfers between B and C are simply money juggling around between two accounts I own.  Thus my earnings are never in the B-&gt;C channel, but in the (public!) A-&gt;B channel.  So attacking B will still allow hackers to take my earnings, because B-&gt;C only contains savings.  Indeed I probably take *more* risk here, since I need to fund B-&gt;C rather than, say, keep that money in a cold storage paper in a locked vault buried beneath concrete somewhere in the jungles of Africa (I would like to take the time to note that this is not where I actually keep my cold storage).<br></div><div><br></div><div>Which is not to say this is completely worthless.  Perhaps B and C are owned by different entities: B takes on risk, and in exchange charges a larger-than-usual feerate for the B-&gt;C channel transfers.<br></div><div><br></div><div>Alternatively, perhaps I am a large conglomerate and I have multiple subsidiaries.  I might create a single public access node and several private nodes for each of my subsidiaries, giving one larger-than-normal (&gt;16777215 satoshi) channel for each subsidiary.  I take actual earnings from my single public node, and then each of my subsidiaries implicitly gives a report of how much they earned (I simply look up how much of each private channel belongs belongs to the subsidiary private node; this is equivalent to what the subsidiary earned).<br></div><div><br></div><div>But I do not think it is possible for a single entity to use this to manage its own risk.  Perhaps indeed &quot;hubs&quot; will arise who take on the risk of being a public node with possibly large amounts of money in their channels, and create private channels to their clients, which at least are trustless since the client can drop the channel onchain if they lose trust in the hub (i.e. it is still a better situation than current &quot;merchant accounts&quot; offered by exchanges, where you cannot get your money out if the exchange decides you are unworthy).<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div></div></div>