From fiatjaf at gmail.com Mon Dec 20 16:06:41 2021 From: fiatjaf at gmail.com (fiatjaf) Date: Mon, 20 Dec 2021 13:06:41 -0300 Subject: [Lightning-dev] Payment sender authentication In-Reply-To: References: Message-ID: Hi Joost, On Mon, Dec 20, 2021 at 5:02 AM Joost Jager wrote: > Hi fiatjaf and peter, > > On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote: > >> As a temporary solution, I suggest taking a look at >> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that >> you can either provide >> - a lone pubkey (to be used for manually identifying the payer later if >> necessary); >> - a domain-specific pubkey along with a signature of a challenge >> provided by the receiver; or >> - an unauthenticated name or email (for light things like donations for >> which one may not care very much about cryptographic authentication). >> And then you commit these things, whatever they are, inside the BOLT11 >> payment request using the 'h' tag. >> > > Interesting read. I see it uses a signature, but is that a good idea? It > could allow the receiver to prove to a 3rd party that the payment was made. > I guess it depends on the application if that is desired or not. The more > privacy conscious users would probably try to avoid committing to data via > a signature. > Just to clarify: For the lone pubkey method there are no privacy implications I think, since it's just a random pubkey and can be used later only if needed in some custom way. For the signature method the privacy implications are close to none (unless I'm missing something) because the key used to sign is (supposed to be) generated by a method that makes it specific to the DNS domain of the service being paid. Since this assumes an LNURL request that has a domain, the key will be generated with something like `HMAC(domain, seed_key)` (the specifics don't matter) so it will not be possible for anyone to relate that signature to anyone. Only the receiver service will be able to relate it to other payments (or logins) to that same exact service -- which can prove quite handy in many cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: