fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-20 📝 Original message: Hi Joost, On Mon, Dec 20, ...
📅 Original date posted:2021-12-20
📝 Original message:
Hi Joost,
On Mon, Dec 20, 2021 at 5:02 AM Joost Jager <joost.jager at gmail.com> wrote:
> Hi fiatjaf and peter,
>
> On Sat, Dec 18, 2021 at 2:08 PM fiatjaf <fiatjaf at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/d98a888e/attachment.html>;
📝 Original message:
Hi Joost,
On Mon, Dec 20, 2021 at 5:02 AM Joost Jager <joost.jager at gmail.com> wrote:
> Hi fiatjaf and peter,
>
> On Sat, Dec 18, 2021 at 2:08 PM fiatjaf <fiatjaf at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/d98a888e/attachment.html>;