BLIP 0014: add sender authentication #14
Conversation
joostjager
force-pushed
the
sender-auth
branch
from
518cb06
to
91674d6
Compare
joostjager
changed the title
joostjager
force-pushed
the
sender-auth
branch
from
91674d6
to
f7982ca
Compare
blip-0014.md
Outdated
|
|
||
| `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)` |
There was a problem hiding this comment.
I think just using either payment_hash or payment_secret could be sufficient, but including them both to be sure.
joostjager
force-pushed
the
sender-auth
branch
from
f7982ca
to
0d74c69
Compare
blip-0014.md
Outdated
| 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). |
There was a problem hiding this comment.
Using 8 bytes to circumvent the year 2038 problem.
joostjager
force-pushed
the
sender-auth
branch
3 times, most recently
from
67d3e11
to
c89a4e4
Compare
| `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` |
There was a problem hiding this comment.
Maybe go for Schnorr right from the start so that we can use musig?
There was a problem hiding this comment.
The downside is that it is not so easy to do simple signing with the ECDSA node key anymore.
There was a problem hiding this comment.
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.
|
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
force-pushed
the
sender-auth
branch
from
c89a4e4
to
0250d93
Compare
|
Added a few example use cases |
joostjager
force-pushed
the
sender-auth
branch
from
0250d93
to
9c4d8f8
Compare
There was a problem hiding this comment.
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.
| * 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 |
There was a problem hiding this comment.
Wouldn't this be simpler by just exposing an invoice?
There was a problem hiding this comment.
This would also work with keysend/AMP.
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
Good point. I appreciate that you take the effort to kill my use cases :)
|
|
||
| Example use cases: | ||
|
|
||
| * A donation payment where the donor wants to make themselves known. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yes agreed. I am brainstorming a bit here to see what use cases make sense.
There was a problem hiding this comment.
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)
| `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` |
There was a problem hiding this comment.
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.
|
|
||
| * A donation payment where the donor wants to make themselves known. | ||
|
|
||
| * Regulated custodial wallets that can offer higher receive limits for payments |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
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. |
|
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. |
|
Ugh, this slipped off my radar.
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. |
|
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? |
Adds the possibility for the sender to optionally authenticate themselves. More background: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-December/003422.html