ZmnSCPxj <zmnsc...@protonmail.com> writes: >> 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.
Excellent point, but I think there are more advantages to having a node separate from the gateway as source of truth. Let's assume the gateway node, exposed directly to the open network is compromised, that still means that an eventual store independently verifies incoming payments, i.e., it is not possible for the compromised node to escalate to the store, without also compromising the hidden nodes. If however the gateway node provides the ground truth for the store, then the attacker could just mark all of the attacker's invoices as complete and thus steal goods from the shop. The attacker is limited to drain the B -> C channel, to steal goods from the store, until it gets rebalanced. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev