Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-09 📝 Original message: > Connect is not the same ...
📅 Original date posted:2018-04-09
📝 Original message:
> 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.
This is outside of the spec, isn't it? All implementations should use a
seed service to bootstrap themselves to the network.
> 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.
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 "autoconnect" because that's the terminology in the mobile
wallet, but it is misleading.
I hope the additional text I'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.
> I am not sure how the risk gets managed if the public and private nodes
are owned by the same economic entity.
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 "warm" funds in your example sit on the C side of the B -> C channel.
Regarding "hubs", I think that while the barrier to entry into running
multiple nodes isn't zero, it'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.
Best,
Tyler
On Mon, Apr 9, 2018 at 7:31 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/20180410/8bda40cb/attachment-0001.html>;
📝 Original message:
> 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.
This is outside of the spec, isn't it? All implementations should use a
seed service to bootstrap themselves to the network.
> 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.
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 "autoconnect" because that's the terminology in the mobile
wallet, but it is misleading.
I hope the additional text I'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.
> I am not sure how the risk gets managed if the public and private nodes
are owned by the same economic entity.
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 "warm" funds in your example sit on the C side of the B -> C channel.
Regarding "hubs", I think that while the barrier to entry into running
multiple nodes isn't zero, it'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.
Best,
Tyler
On Mon, Apr 9, 2018 at 7:31 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/20180410/8bda40cb/attachment-0001.html>;