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

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

Re: [Lightning-dev] Lightning network user identification

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

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

Re: [Lightning-dev] Lightning network user identification

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

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