ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-09 📝 Original message: Good morning Tyler, > A ...
📅 Original date posted:2018-04-09
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/28e90e01/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/28e90e01/attachment.html>;