Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-10 📝 Original message: Christian, ZmnSCPxj et ...
📅 Original date posted:2018-04-10
📝 Original message:
Christian, ZmnSCPxj et al,
Your concerns have been taken seriously, and while this might provide some
useful features with regard to opening appropriate channels (and I guess
can be implemented outside of spec, if an implementation so wishes), after
consideration and some very useful feedback from Olaoluwa Osuntokun on the
LND slack, I've decided to pull my support for implementing this specific
proposal as part of this spec.
To summarize the primary issue with this proposed BOLT:
DNS in its current form cannot be trusted as part of the Lightning spec,
plain and simple.
While I've rescinded my support, I don't discourage thoughtful
implementation of functionality like this, but I do caution any
implementation to properly inform the user as to the inherent risk in
trusting DNS, and only use DNS records as a way to increase confidence, not
make guarantees, that a node is associated to the domain it says it is.
I will continue to approach the problem of securely advertising
human-understandable node names, and I hope someday soon I will have a
solution Lightning can use that retains the open, decentralized properties
of the technology and the underlying blockchains.
I leave this proposal in Robert's hands to further defend if he wishes, and
I would discourage future proposals largely similar to this but on other
authenticated technologies (for example, advertising node information via
forum posts). Any information that doesn't come from the network itself
cannot be backed by cryptographic guarantees.
Other discussions regarding public vs private nodes and channel structures
are encouraged.
Best regards,
Tyler
On Tue, Apr 10, 2018 at 5:23 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/2817880e/attachment-0001.html>;
📝 Original message:
Christian, ZmnSCPxj et al,
Your concerns have been taken seriously, and while this might provide some
useful features with regard to opening appropriate channels (and I guess
can be implemented outside of spec, if an implementation so wishes), after
consideration and some very useful feedback from Olaoluwa Osuntokun on the
LND slack, I've decided to pull my support for implementing this specific
proposal as part of this spec.
To summarize the primary issue with this proposed BOLT:
DNS in its current form cannot be trusted as part of the Lightning spec,
plain and simple.
While I've rescinded my support, I don't discourage thoughtful
implementation of functionality like this, but I do caution any
implementation to properly inform the user as to the inherent risk in
trusting DNS, and only use DNS records as a way to increase confidence, not
make guarantees, that a node is associated to the domain it says it is.
I will continue to approach the problem of securely advertising
human-understandable node names, and I hope someday soon I will have a
solution Lightning can use that retains the open, decentralized properties
of the technology and the underlying blockchains.
I leave this proposal in Robert's hands to further defend if he wishes, and
I would discourage future proposals largely similar to this but on other
authenticated technologies (for example, advertising node information via
forum posts). Any information that doesn't come from the network itself
cannot be backed by cryptographic guarantees.
Other discussions regarding public vs private nodes and channel structures
are encouraged.
Best regards,
Tyler
On Tue, Apr 10, 2018 at 5:23 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/2817880e/attachment-0001.html>;