Re: [Lightning-dev] Lightning network user identification

2019-01-29 Thread Joao Joyce
Hi ZmnSCPxj,

Yeah, although I see the added value of a feature like this I completely 
understand your reasoning.

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

Sure, people and corporations would probably find multiple ways to abuse this 
or to turn this into the only way to make LN payments.

The problem of moving some of this stuff to the hardware of the user is the 
lack of standardisation. I don’t know if there’s any wallet that currently does 
this kind of stuff. I’m not even sure if wallets should do it. 
Or if other Apps should be given access to pre-images of LN payments. 

I guess that I was expecting that a replacement for email/password as 
authentication method could finally come from something I’m hopping will be as 
pervasive as email addresses :)
Anyway, authentication might be completely out of scope here. 

Thank you,
João  Joyce
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Lightning network user identification

2019-01-28 Thread ZmnSCPxj via Lightning-dev
Good morning Joao?


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, January 28, 2019 10:39 AM, Joao Joyce  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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Lightning network user identification

2019-01-27 Thread Joao Joyce
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?

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...

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

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?

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...

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...


De: ZmnSCPxj 
Enviado: 28 de janeiro de 2019 01:21:13
Para: Joao Joyce
Cc: lightning-dev@lists.linuxfoundation.org
Assunto: Re: [Lightning-dev] Lightning network user identification

Good morning Joao,


>
> Eventually I could use something like SQRL or BitID which enable some level 
> of anonymity. But now the user would have to keep an app for login and 
> another for payments. He is expected to have both apps to use the service and 
> keep both private keys secure. Both would use QR codes which makes for a lot 
> of confusion and a terrible user experience. Of course I would have to 
> eventually code the email/password anyway as a fall back.
>
> Contrast this scenario with this one which is basically identical to the one 
> in the video:
> 1 - User goes to the ebook store.
> 2 - User selects the book he wants and scan a LN invoice.
> 3 - Wallet shows payment info and asks if user wants to provide his identity.
> 4 - User confirms payment and identity in the same action.
>
> There was no need for the user to create an account or to log in to the 
> service. And no need for the store to keep any private data, just a unique 
> userID that is only valid for that particular store.

Why is not the proof-of-payment sufficient?
Service generates a secret, user pays for the secret, proof of knowledge of 
secret authorizes use of the book.

In short, use the payment preimage as "unique userID".
You also automatically ensure that userIDs are usable only if paid for.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Lightning network user identification

2019-01-27 Thread ZmnSCPxj via Lightning-dev
Good morning Joao,


>
> Eventually I could use something like SQRL or BitID which enable some level 
> of anonymity. But now the user would have to keep an app for login and 
> another for payments. He is expected to have both apps to use the service and 
> keep both private keys secure. Both would use QR codes which makes for a lot 
> of confusion and a terrible user experience. Of course I would have to 
> eventually code the email/password anyway as a fall back.
>
> Contrast this scenario with this one which is basically identical to the one 
> in the video:
> 1 - User goes to the ebook store.
> 2 - User selects the book he wants and scan a LN invoice.
> 3 - Wallet shows payment info and asks if user wants to provide his identity.
> 4 - User confirms payment and identity in the same action.
>
> There was no need for the user to create an account or to log in to the 
> service. And no need for the store to keep any private data, just a unique 
> userID that is only valid for that particular store.

Why is not the proof-of-payment sufficient?
Service generates a secret, user pays for the secret, proof of knowledge of 
secret authorizes use of the book.

In short, use the payment preimage as "unique userID".
You also automatically ensure that userIDs are usable only if paid for.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Lightning network user identification

2019-01-27 Thread Joao Joyce
Hi ZmnSCPxj,

Thank you for your thoughtfull input.

Let me just clarify that I share the same concerns regarding user privacy. I do 
value all the work that’s being done to keep the LN private, trustless and 
permissionless.

My intention is not to violate user privacy but to give an option for a user to 
opt-in on keeping and proving a single identity across multiple payments for 
the same store (different stores would have different IDs, kind of like what 
happens in SQRL).

This would not be something that would happen by default or on most LN payment, 
but on specific payments.

The wallet would always make the user aware of it. You could probably even 
opt-in/out of this feature on the moment the payment is made.

In certain cases I believe this could enable a higher level of privacy and a 
smooth transition to better authentication practices.

For instance, I’ve implement a simple PoC service, where a user can go to an 
ebook store and pay a LN invoice to buy an ebook directly on the ereader device 
(https://youtu.be/b1w-W6oMb_M).

But then I was thinking that I eventually would need to have a way to let the 
user prove that he had already bought a book in order to redownload it. 
Authenticating the user and keeping a user account immediately comes to mind. 
Users are used to it.

But now I would have to make the user go through a create account/login flow, 
eventually asking more personal info like emails and passwords, keeping that 
data safe, etc...I don’t want none of that private data!

Also I would have to write more code...

Eventually I could use something like SQRL or BitID which enable some level of 
anonymity. But now the user would have to keep an app for login and another for 
payments. He is expected to have both apps to use the service and keep both 
private keys secure. Both would use QR codes which makes for a lot of confusion 
and a terrible user experience. Of course I would have to eventually code the 
email/password anyway as a fall back.

Contrast this scenario with this one which is basically identical to the one in 
the video:
1 - User goes to the ebook store.
2 - User selects the book he wants and scan a LN invoice.
3 - Wallet shows payment info and asks if user wants to provide his identity.
4 - User confirms payment and identity in the same action.

There was no need for the user to create an account or to log in to the 
service. And no need for the store to keep any private data, just a unique 
userID that is only valid for that particular store.

On the larger picture I was thinking that the standardization of such a 
payment/auth flow could enable services to easily transition from 
email/password flows to a more anonymous and secure method of private and 
public keys and that all those capabilities would come for free for every LN 
user and every LN store.

Also new use cases like the ones described in the previous email would become 
possible.

Simple LN payments would coexist with this method. Private, anonymous, 
non-tracking and perfect as they are.

Thanks,
João Joyce

De: ZmnSCPxj 
Enviado: 27 de janeiro de 2019 16:13:12
Para: Joao Joyce
Cc: lightning-dev@lists.linuxfoundation.org
Assunto: Re: [Lightning-dev] Lightning network user identification

Good morning Joao,

Currently no.
Also, why would you want to violate user privacy in exchange for a service?
You should authorize usage depending on secrets the user knows, not depending 
on their "identity".

This is precisely why LN is set up to use zero-knowledge contingent payments.
You release a secret in exchange for money.
Then, you authorize the service (streaming data, discount, etc) if someone is 
able to present proof that they know that secret.

I admit the current proof-of-payment is limited, especially since the secret is 
sent to each intermediate node.
However, use of payment points and scalars (instead of hashes and preimages) 
will eventually be deployed, which would hide the secret being paid for from 
the intermediate nodes.
In addition, proof of knowledge of a secret is simply a signature algorithm 
(points are public keys, scalars are secret keys).

From this point of view, your "user" is simply someone who knows the secret 
that you released when you were paid for your service.
Physical instances of humanity should be allowed to share a single "user", or 
have multiple "users"; you will be paid according to your service anyway.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, January 27, 2019 5:09 AM, Joao Joyce  wrote:

> Hi all,
>
> I was wondering if there is a way to identify a user across multiple LN 
> requests or even authenticate the user in a single step using a LN wallet.
>
> Some use cases.
>
> -   A companyadvertising a pay-per-view event could make billboards/posters 
> with LN QR-codes. By scanning the code on the billboar

Re: [Lightning-dev] Lightning network user identification

2019-01-27 Thread ZmnSCPxj via Lightning-dev
Good morning Joao,

Currently no.
Also, why would you want to violate user privacy in exchange for a service?
You should authorize usage depending on secrets the user knows, not depending 
on their "identity".

This is precisely why LN is set up to use zero-knowledge contingent payments.
You release a secret in exchange for money.
Then, you authorize the service (streaming data, discount, etc) if someone is 
able to present proof that they know that secret.

I admit the current proof-of-payment is limited, especially since the secret is 
sent to each intermediate node.
However, use of payment points and scalars (instead of hashes and preimages) 
will eventually be deployed, which would hide the secret being paid for from 
the intermediate nodes.
In addition, proof of knowledge of a secret is simply a signature algorithm 
(points are public keys, scalars are secret keys).

From this point of view, your "user" is simply someone who knows the secret 
that you released when you were paid for your service.
Physical instances of humanity should be allowed to share a single "user", or 
have multiple "users"; you will be paid according to your service anyway.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, January 27, 2019 5:09 AM, Joao Joyce  wrote:

> Hi all,
>
> I was wondering if there is a way to identify a user across multiple LN 
> requests or even authenticate the user in a single step using a LN wallet.
>
> Some use cases.
>
> -   A companyadvertising a pay-per-view event could make billboards/posters 
> with LN QR-codes. By scanning the code on the billboard the user would buy 
> the right to see the event later that night. This would happen in just one 
> step, no need for login, just like a regular LN payment.
> -   A music-streaming company could print QR-codes on posters. By scanning 
> the code the user would imediately get the album on the music-streaming app 
> on his phone.
> -   A user could anonymously get frequent-user discounts or reward points on 
> vending machines or similar services.
> -   An arcade game like this one 
> (https://www.youtube.com/watch?v=U0KUNbjFZdk) could identify the user across 
> multiple plays and different machines and provide the user with high-scores 
> and user performance statistics.
> -   Arcade games could provide multi player gaming keeping user identity, 
> scores, in-game items, etc...
>
> Is this currently possible?
>
> Thank you,
> João Joyce


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev