📅 Original date posted:2021-12-20
📝 Original message:
On Mon, Dec 20, 2021 at 09:01:37AM +0100, Joost Jager wrote:
> 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.
The key thing is the invoice has to get to the sender somehow in the first
place. So I don't think there's any reason to use the lightning protocol itself
for additional authentication.
> > 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.
The purpose of diffie-hellman is to generate a shared secret in the absense of
a secure channel. Once you have a secure channel there's no reason to use it.
Simply giving the sender the payment info is sufficient.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/3d42edd8/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-09 13:04:54
in reply to nevent1q…vv0h
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-09 13:04:54Event JSON
{
"id": "bc94ca5f644a13ffa4e4d0fed88dc7dc9c9fd66d592ae3c4b45d40c30932ae26",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686315894,
"kind": 1,
"tags": [
[
"e",
"810214f854fe6be826cefef7d85836e0f64f01c05816d59fc986f88c3b571982",
"",
"root"
],
[
"e",
"a9eb4f8dbd1fb7c64dd86c16f0d3ba6e4700174837134557bd23f1239caf08ab",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2021-12-20\n📝 Original message:\nOn Mon, Dec 20, 2021 at 09:01:37AM +0100, Joost Jager wrote:\n\u003e On Sat, Dec 18, 2021 at 6:56 PM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e Lightning already has sender authentication: you simply give someone a\n\u003e \u003e pre-image hash over an authenticated channel, and the fact that the\n\u003e \u003e payment was\n\u003e \u003e made means only they could have realistically made it as they were the only\n\u003e \u003e person who knew that pre-image hash.\n\u003e \u003e\n\u003e \n\u003e This sounds quite similar to what is described above in lnurl-18. I can see\n\u003e that that works, but I should have added that I was looking for a solution\n\u003e that exists completely within the protocol without using an additional\n\u003e channel. Also, routing nodes learn the preimage hash too, so the sender\n\u003e isn't the only person. But that is solved by the payment secret that is\n\u003e also part of the invoice.\n\nThe key thing is the invoice has to get to the sender somehow in the first\nplace. So I don't think there's any reason to use the lightning protocol itself\nfor additional authentication.\n\n\u003e \u003e Going beyond that is dangerous as you're creating the ability to prove to a\n\u003e \u003e *third* party who made a particular payment. That raises serious problems\n\u003e \u003e in\n\u003e \u003e cases like government raids that need to be considered very carefully.\n\u003e \n\u003e \n\u003e This is why I proposed to use diffie-hellman to generate a shared secret.\n\u003e The receiver could then have made up all the proofs themselves and are\n\u003e therefore of no value to a third party.\n\nThe purpose of diffie-hellman is to generate a shared secret in the absense of\na secure channel. Once you have a secure channel there's no reason to use it.\nSimply giving the sender the payment info is sufficient.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/3d42edd8/attachment.sig\u003e",
"sig": "85cb9fee60688e907aed3419a20e0f9ba1b414bee51c77e312954d798c5b2396873a3678a5c000fdb5262340143bc78929c8f6ac04dca7adc90c81d5a6cf5883"
}