ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-10 📝 Original message: Good morning Tyler, > The ...
📅 Original date posted:2018-04-10
📝 Original message:
Good morning Tyler,
> The external party idea is interesting, but I'm fearful that it can't be done in a way that retains a bare minimum of privacy.
No, of course not. "Private" channels are privacy sieves and should not be used by privacy-conscious entities. Since the channel is never published the "public" side knows that any economic activity going through the "private" channel must terminate on the other side.
Perhaps better terms would be "published" and "unpublished" channels. We should really warn people that use of unpublished channels leaks your economic information, whereas use of published channels give the plausible deniability that it could be somebody else using that channel, not you.
You could try contracting out to multiple external parties, so that at least no single entity knows *all* your economic activity. You still leak all your economic activity, you are simply hoping that those external parties do not pool their information together to get a complete profile of you. Seems like a quixotic endeavor. You may be better off using your own public node.
Multiple public nodes may be useful for load distribution. You could also try implementation diversity, using different secure operating system, hardware, and LN node software for each node, in the hope that 0days have lower probability of affecting them all simultaneously.
You could have multiple public nodes A <-> B with a published channel between them that is larger than normally allowed; many of the issues with large channels disappear when you know that you can trust each other. and if you really own both A and B, then you know A can trust B and vice versa. The purpose is load distribution: you could source half your invoices with one and half your invoices with the other, and the channel between them allows customers to use e.g. a channel to A to pay an invoice made by B when all other published channels to B are depleted. But in terms of hackability, you should really not make A trust B and vice versa, though.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/5ed0d7c2/attachment-0001.html>;
📝 Original message:
Good morning Tyler,
> The external party idea is interesting, but I'm fearful that it can't be done in a way that retains a bare minimum of privacy.
No, of course not. "Private" channels are privacy sieves and should not be used by privacy-conscious entities. Since the channel is never published the "public" side knows that any economic activity going through the "private" channel must terminate on the other side.
Perhaps better terms would be "published" and "unpublished" channels. We should really warn people that use of unpublished channels leaks your economic information, whereas use of published channels give the plausible deniability that it could be somebody else using that channel, not you.
You could try contracting out to multiple external parties, so that at least no single entity knows *all* your economic activity. You still leak all your economic activity, you are simply hoping that those external parties do not pool their information together to get a complete profile of you. Seems like a quixotic endeavor. You may be better off using your own public node.
Multiple public nodes may be useful for load distribution. You could also try implementation diversity, using different secure operating system, hardware, and LN node software for each node, in the hope that 0days have lower probability of affecting them all simultaneously.
You could have multiple public nodes A <-> B with a published channel between them that is larger than normally allowed; many of the issues with large channels disappear when you know that you can trust each other. and if you really own both A and B, then you know A can trust B and vice versa. The purpose is load distribution: you could source half your invoices with one and half your invoices with the other, and the channel between them allows customers to use e.g. a channel to A to pay an invoice made by B when all other published channels to B are depleted. But in terms of hackability, you should really not make A trust B and vice versa, though.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/5ed0d7c2/attachment-0001.html>;