[Lightning-dev] Lightning network user identification

[ZmnSCPxj]

Good morning Joao?


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 28, 2019 10:39 AM, Joao Joyce <joao.joyce at netcabo.pt> wrote:

> Ok, that would work for this particular case which is of course a very simple PoC. But the problem of connecting multiple payments to a user account still stands, or am I missing something?

Why does the *service* need to connect multiple payments to a user account?

>
> And the user would also be required to keep a copy of the pre-image for every bought item right? It feels like just holding a priv key should be enough to get all my books, items, account info...

Make the user software record locally on the user's device, encrypted with the user's priv key.
Why should the service do this?
The entire point of Bitcoin and Lightning is for each entity to be able to stand for itself.

In short, let the user software handle management of all the preimages for all items it bought.
The "user identity" is thus a virtual one that is created by the user software.
Similarly, a "Bitcoin wallet" is a virtual wallet created by the user software; what actually exists onchain is addresses, not wallets.

>
> I get that there might be implementation and UX issues around something like this but I’m not seeing the privacy risks around it.

I do not want anyone, not even vendors, to link my purchase of Strawberry Shortcake paraphernalia with my purchase of XXXtra-Slippery Lubribation Oil.
My use of Strawberry Shortcake paraphernalia is my own private affair and whether I reveal it or not is my right.

>
> Why should some of these use cases be ruled out preventively and not just pass that responsibility to the user who might benefit from them?

Why do you think that this "ruling out" prevents the user from being responsible?
It *forces* the user to be responsible since it is the user software, running on the user hardware, that handles the user-owned digital library.

At the same time, it reduces the privacy leakage since vendors are not able to link different purchases to the same user, at least on LN.
(Leakage from IP addresses on the other hand...)

>
> As a user I think I wouldn’t mind giving permission for a service to keep my high scores or all the books I got, or all the music I bought in the same account...

*You* might not.
I would mind.


>
> And if that can be done in a single step, opted-in and I don’t even need to provide any personal info that could lead to my “human identity” even better! That would be a major improvement from most services now who force you to have an email account which can most of the time give a lot of information about someone and provide them a password which, who knows what they do with it and how they store it...

And how is this an improvement from the case where the "human identity" is handled by an application on the user-owned hardware?

In any case, the principle is simple.
We must consider privacy first, and allow users to leak information if they are willing.
But such information leakage MUST NOT be required for any purchase.

Thus, there is no need for the LN base network to provide some kind of persistent user ID.
Higher layers may do so selectively, but would be foolish to support such a thing.

It is difficult to regain privacy if the base layer is nonprivate.


Regards,
ZmnSCPxj