BLIP 0014: add sender authentication #14

joostjager · 2022-02-04T09:29:02Z

Adds the possibility for the sender to optionally authenticate themselves. More background: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003422.html

joostjager · 2022-02-07T17:43:37Z

blip-0014.md

+
+  `signature` is a DER-encoded ECDSA signature calculated using `sender_pubkey` over the message:
+
+  `recipient_pubkey (33 bytes) | payment_hash (32 bytes) | payment_secret (32 bytes) | amount_msat (8 bytes)`


I think just using either payment_hash or payment_secret could be sufficient, but including them both to be sure.

joostjager · 2022-02-07T17:53:15Z

blip-0014.md

+  need to be the sender's node public key. It can also be a more general
+  identity.
+
+  `timestamp` is timestamp in nano seconds since unix epoch (big endian encoded).


Using 8 bytes to circumvent the year 2038 problem.

joostjager · 2022-02-07T18:10:42Z

blip-0014.md

+  `timestamp` is the payment initiation time in nano seconds since unix epoch
+  (big endian encoded).
+
+  `signature` is a DER-encoded ECDSA signature calculated using `sender_pubkey`


Maybe go for Schnorr right from the start so that we can use musig?

The downside is that it is not so easy to do simple signing with the ECDSA node key anymore.

I guess it depends a lot on the specific use-cases here. Its still somewhat unclear to me what the intended use-case is here.

TheBlueMatt · 2022-02-08T16:44:06Z

It'd be nice to have a rationale section that discusses potential uses for this (and arguably more importantly, cases where this should not be used). eg if you're doing some kind of chat over lightning HTLCs, you probably don't want to use this and instead want to do some kind of double-ratchet thing, and also just talk about how this is generally discouraged for every-day usage.

joostjager · 2022-02-09T19:29:46Z

Added a few example use cases

TheBlueMatt

I'm not against having a specification for this, but one concern with this kind of document is that people see it and implement it "because its a spec". This is a common problem we see in the BIP world - there are many BIPs that are genuinely really bad ideas and shouldn't ever be use, but get broad use because people see BIPs as a repo of "good ideas". One potential way to document this would be to make very clear in the use-cases section that this is explicitly a bad idea for general use, and should be used only when you're doing something highly specific.

IOW, describing that "general purpose" lightning wallets should almost certainly never implement this, and describe how cases where exchanges want to know the sender should simply display invoices to logged-in users instead.

TheBlueMatt · 2022-02-09T19:39:06Z

blip-0014.md

+* Regulated custodial wallets that can offer higher receive limits for payments
+  originating from specific sources.
+
+* Lightning deposits to an exchange where the exchange automatically credits the


Wouldn't this be simpler by just exposing an invoice?

This would also work with keysend/AMP.

Yes, that doesn't mean we should encourage people to use keysend+sender auth over an invoice, especially for exchange deposits, where proof-of-payment is really important :).

Good point. I appreciate that you take the effort to kill my use cases :)

TheBlueMatt · 2022-02-09T19:41:20Z

blip-0014.md

+
+Example use cases:
+
+* A donation payment where the donor wants to make themselves known.


Is a signature the best way to do this? Vs, eg, just shoving a name in the TLV? I guess its a question of what you're trying to make known - trying to prove that a given public key sent the funds seems like a somewhat strange use-case, but, sure.

Yes agreed. I am brainstorming a bit here to see what use cases make sense.

FYI I currently have a proprietary TLV that is just sending a simple non-authenticated name to the receiver, which I intend to make a BLIP of.

https://github.com/hsjoberg/blixt-wallet/blob/c79cc4b9e3532400cfd648047f132eb35f10fdf4/src/utils/constants.ts#L5
https://github.com/hsjoberg/blixt-wallet/blob/c79cc4b9e3532400cfd648047f132eb35f10fdf4/src/lndmobile/index.ts#L181

It could make sense to expand this BLIP to cover various use-cases (akin to how LNURL's LUD-18 payerid works)

TheBlueMatt · 2022-02-09T19:42:03Z

blip-0014.md

+  `timestamp` is the payment initiation time in nano seconds since unix epoch
+  (big endian encoded).
+
+  `signature` is a DER-encoded ECDSA signature calculated using `sender_pubkey`


I guess it depends a lot on the specific use-cases here. Its still somewhat unclear to me what the intended use-case is here.

TheBlueMatt · 2022-02-09T19:42:42Z

blip-0014.md

+
+* A donation payment where the donor wants to make themselves known.
+
+* Regulated custodial wallets that can offer higher receive limits for payments


I mean I guess we'd all be incredibly depressed to see anyone actually deploy this proposal for something like this. Shouldn't we instead push people to use invoices for this?

Regulated custodial wallets may not be allowed to accept unlimited deposits from unknown sources. An invoice doesn't help with additional information on the origin of the payment?

This doesn't prove origin, either, this is a signature from a public key. That could totally come from a third party node as much as they could come from the sender.

Also true. It doesn't prove the origin, but if you know that the owner of a particular key uses it exclusively to sign their own outgoing payments it does help with this use case?

Let's say you use a custodial wallet that allows a max of 500 euro/day in lightning deposits and you want to receive your 1000 euro monthly-paid salary via lightning.

Adding your employer's public key to the custodial wallet's allow list raises the limit and allows you to receive that payment.

Although the question here is again how this can be done spontaneously and whether https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md would be a better choice.

Adding your employer's public key to the custodial wallet's allow list raises the limit and allows you to receive that payment.

Right, but you'd also need your employer to configure their node to send this kind of signature to the counterparty when sending a keysend payment, which hopefully will never be an automatic thing. If you want to steelman this use-case I think it'd be the kind of travel-rule nonsense folks deal with today (though that's currently only withdraws, not deposits), where a regulated institution needs legal assurance the recipient of a payment is not a regulated financial institution (or if it is, which one).

In that context, you could argue that regulated institutions could use this to prove to recipients that they are the ones who sent it, though that sadly doesn't fulfill the travel rule obligations, but it could help.

TheBlueMatt · 2022-02-09T22:11:17Z

One potential use-case we could describe here would be where a sender is a regulated financial institution sending to a pubkey it knows is another regulated financial institution, where they wish to indicate to the recipient who they are by means of node id authentication, and then presumably they will exchange some additional information out-of-band to fulfill their travel rule obligations.

joostjager · 2022-02-10T08:34:08Z

In that case, can't they make a regular lightning payment without sender auth and send the additional info along with the payment hash and/or payment secret out-of-band?

I think in-protocol authentication can be helpful to do just-in-time limits checking. You don't want to end up accepting payments that then need to be held or refunded. Another option is to use lnurl or some other out-of-band communication mechanism to preclear the transaction.

TheBlueMatt · 2022-04-30T01:08:07Z

Ugh, this slipped off my radar.

In that case, can't they make a regular lightning payment without sender auth and send the additional info along with the payment hash and/or payment secret out-of-band?

No, they shouldn't/wouldn't want to send KYC info to everyone, they really want to authenticate themselves as a legitimate institution to the recipient, with the recipient authenticating themselves as a legitimate institution back to the sender as well. Only if they both trust each other should they exchange KYC info.

t-bast · 2024-09-18T11:08:47Z

Has this actually been used by someone? Looking at pending blips, it seems to me that #31 would fit the same needs with better trade-offs?

t-bast · 2024-12-12T16:44:35Z

Closing for inactivity, feel free to re-open if someone is actually working on this.

joostjager force-pushed the sender-auth branch from 518cb06 to 91674d6 Compare February 4, 2022 09:30

joostjager mentioned this pull request Feb 4, 2022

BOLT 4: Add sender authentication lightning/bolts#946

Closed

joostjager changed the title ~~add sender authentication~~ BLIP 0014: add sender authentication Feb 4, 2022

joostjager force-pushed the sender-auth branch from 91674d6 to f7982ca Compare February 7, 2022 17:42

joostjager commented Feb 7, 2022

View reviewed changes

joostjager force-pushed the sender-auth branch from f7982ca to 0d74c69 Compare February 7, 2022 17:50

joostjager commented Feb 7, 2022

View reviewed changes

joostjager force-pushed the sender-auth branch 3 times, most recently from 67d3e11 to c89a4e4 Compare February 7, 2022 18:04

joostjager commented Feb 7, 2022

View reviewed changes

joostjager force-pushed the sender-auth branch from c89a4e4 to 0250d93 Compare February 9, 2022 19:29

add sender authentication

9c4d8f8

joostjager force-pushed the sender-auth branch from 0250d93 to 9c4d8f8 Compare February 9, 2022 19:34

TheBlueMatt reviewed Feb 9, 2022

View reviewed changes

t-bast closed this Dec 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BLIP 0014: add sender authentication #14

BLIP 0014: add sender authentication #14

joostjager commented Feb 4, 2022 •

edited

Loading

joostjager Feb 7, 2022 •

edited

Loading

joostjager Feb 7, 2022

joostjager Feb 7, 2022

joostjager Feb 9, 2022

TheBlueMatt Feb 9, 2022

TheBlueMatt commented Feb 8, 2022

joostjager commented Feb 9, 2022

TheBlueMatt left a comment

TheBlueMatt Feb 9, 2022

joostjager Feb 9, 2022

TheBlueMatt Feb 9, 2022

joostjager Feb 9, 2022

TheBlueMatt Feb 9, 2022

joostjager Feb 9, 2022

hsjoberg Feb 16, 2022 •

edited

Loading

TheBlueMatt Feb 9, 2022

TheBlueMatt Feb 9, 2022

joostjager Feb 9, 2022

TheBlueMatt Feb 9, 2022

joostjager Feb 9, 2022 •

edited

Loading

joostjager Feb 9, 2022

joostjager Feb 9, 2022

TheBlueMatt Feb 9, 2022

TheBlueMatt commented Feb 9, 2022

joostjager commented Feb 10, 2022

TheBlueMatt commented Apr 30, 2022

t-bast commented Sep 18, 2024

t-bast commented Dec 12, 2024


		`signature` is a DER-encoded ECDSA signature calculated using `sender_pubkey` over the message:

		`recipient_pubkey (33 bytes) \| payment_hash (32 bytes) \| payment_secret (32 bytes) \| amount_msat (8 bytes)`


		Example use cases:

		* A donation payment where the donor wants to make themselves known.


		* A donation payment where the donor wants to make themselves known.

		* Regulated custodial wallets that can offer higher receive limits for payments

BLIP 0014: add sender authentication #14

BLIP 0014: add sender authentication #14

Conversation

joostjager commented Feb 4, 2022 • edited Loading

joostjager Feb 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Feb 8, 2022

joostjager commented Feb 9, 2022

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hsjoberg Feb 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager Feb 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Feb 9, 2022

joostjager commented Feb 10, 2022

TheBlueMatt commented Apr 30, 2022

t-bast commented Sep 18, 2024

t-bast commented Dec 12, 2024

joostjager commented Feb 4, 2022 •

edited

Loading

joostjager Feb 7, 2022 •

edited

Loading

hsjoberg Feb 16, 2022 •

edited

Loading

joostjager Feb 9, 2022 •

edited

Loading