Good morning Tyler,
> 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.
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.
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.
> 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.
I am not sure how the risk gets managed if the public and private nodes are
owned by the same economic entity.
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.
A -> B -> C
Now the channel B->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->C channel, but in the (public!) A->B channel. So attacking B
will still allow hackers to take my earnings, because B->C only contains
savings. Indeed I probably take *more* risk here, since I need to fund B->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).
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->C channel transfers.
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 (>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).
But I do not think it is possible for a single entity to use this to manage its
own risk. Perhaps indeed "hubs" 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 "merchant accounts" offered by exchanges,
where you cannot get your money out if the exchange decides you are unworthy).
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
