-
Notifications
You must be signed in to change notification settings - Fork 46
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
0cd3f84
commit 67d3e11
Showing
2 changed files
with
83 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,82 @@ | ||
``` | ||
bLIP: 14 | ||
Title: Sender authentication | ||
Status: Draft | ||
Author: Joost Jager <[email protected]> | ||
Created: 2022-02-04 | ||
License: CC0 | ||
``` | ||
|
||
## Abstract | ||
|
||
By default, the lightning protocol protects the sender identity by means of | ||
ephemeral keys and onion routing. There are however use cases that ask for | ||
inclusion of the sender identity with a payment. | ||
|
||
This bLIP serves to document a way to authenticate the sender of a payment via a | ||
custom TLV record. | ||
|
||
## Copyright | ||
|
||
This bLIP is licensed under the CC0 license. | ||
|
||
## Specification | ||
|
||
Sender: | ||
|
||
* MUST include a TLV record keyed by type `83231` with the following value: | ||
|
||
* [`33*byte`:`sender_pubkey`] | ||
* [`8*byte`:`timestamp`] | ||
* [`var length`:`signature`] | ||
|
||
`sender_pubkey` is the public key of the sender. Note that `sender_pubkey` doesn't | ||
need to be the sender's node public key. It can also be a more general | ||
identity. | ||
|
||
`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` | ||
over a message that is a concatenation of the following fields: | ||
|
||
* `timestamp` (8 bytes) | ||
* `recipient_pubkey` (33 bytes) | ||
* `payment_hash` (32 bytes) | ||
* `payment_secret` (32 bytes) | ||
* `amount_msat` (8 bytes, big endian) | ||
|
||
For multi-part payments, `amount_msat` is the total amount of the set. The | ||
value of the TLV record MUST be identical for all parts. | ||
|
||
Receiver: | ||
|
||
* MUST verifiy that `signature` is valid and produced using `sender_pubkey`. | ||
|
||
* SHOULD verify that `timestamp` is not unreasonably long ago. Suggested cut-off is | ||
one hour. | ||
|
||
* If verification fails, SHOULD error with | ||
`PERM|15 incorrect_or_unknown_payment_details`. | ||
|
||
## Motivation | ||
|
||
There are many ways to authenticate the sender of a payment in Lightning. This | ||
documentation is an attempt to prevent the emergence of too many variants that | ||
all do more or less the same thing. | ||
|
||
## Rationale | ||
|
||
* The TLV record key is an odd number, meaning that the record is ignored by | ||
receivers that do not support sender authentication. No feature bit is needed. | ||
|
||
* It is possible to recover the public key from an ECDSA signature, so strictly | ||
speaking `sender_pubkey` is redundant. Note that with Schnorr signatures, recovery is no | ||
longer possible. | ||
|
||
* It is undesired that a signature can be reused in any way. Therefore all of | ||
the identifying payment properties are covered by the signature. | ||
|
||
## Test vectors | ||
|
||
TBD |