Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-20 📝 Original message: Hi fiatjaf and peter, On ...
📅 Original date posted:2021-12-20
📝 Original message:
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.
On Sat, Dec 18, 2021 at 6:56 PM Peter Todd <pete at petertodd.org> wrote:
> Lightning already has sender authentication: you simply give someone a
> pre-image hash over an authenticated channel, and the fact that the
> payment was
> made means only they could have realistically made it as they were the only
> person who knew that pre-image hash.
>
This sounds quite similar to what is described above in lnurl-18. I can see
that that works, but I should have added that I was looking for a solution
that exists completely within the protocol without using an additional
channel. Also, routing nodes learn the preimage hash too, so the sender
isn't the only person. But that is solved by the payment secret that is
also part of the invoice.
> Going beyond that is dangerous as you're creating the ability to prove to a
> *third* party who made a particular payment. That raises serious problems
> in
> cases like government raids that need to be considered very carefully.
This is why I proposed to use diffie-hellman to generate a shared secret.
The receiver could then have made up all the proofs themselves and are
therefore of no value to a third party.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/94125b03/attachment.html>;
📝 Original message:
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.
On Sat, Dec 18, 2021 at 6:56 PM Peter Todd <pete at petertodd.org> wrote:
> Lightning already has sender authentication: you simply give someone a
> pre-image hash over an authenticated channel, and the fact that the
> payment was
> made means only they could have realistically made it as they were the only
> person who knew that pre-image hash.
>
This sounds quite similar to what is described above in lnurl-18. I can see
that that works, but I should have added that I was looking for a solution
that exists completely within the protocol without using an additional
channel. Also, routing nodes learn the preimage hash too, so the sender
isn't the only person. But that is solved by the payment secret that is
also part of the invoice.
> Going beyond that is dangerous as you're creating the ability to prove to a
> *third* party who made a particular payment. That raises serious problems
> in
> cases like government raids that need to be considered very carefully.
This is why I proposed to use diffie-hellman to generate a shared secret.
The receiver could then have made up all the proofs themselves and are
therefore of no value to a third party.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/94125b03/attachment.html>;