From c89a4e4932b9610fef43e3471d60233f1205642b Mon Sep 17 00:00:00 2001
From: Joost Jager <joost.jager@gmail.com>
Date: Fri, 4 Feb 2022 10:28:32 +0100
Subject: [PATCH] add sender authentication

---
 blip-0002.md |  1 +
 blip-0014.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 83 insertions(+)
 create mode 100644 blip-0014.md

diff --git a/blip-0002.md b/blip-0002.md
index 668744e..b97a790 100644
--- a/blip-0002.md
+++ b/blip-0002.md
@@ -85,6 +85,7 @@ The following table contains extension tlv fields for the `payment_onion_payload
 
 | Type        | Name                        | Link                           |
 |-------------|-----------------------------|--------------------------------|
+| 83231       | `sender_auth`               | [bLIP 14](./blip-0014.md)      |
 | 7629169     | `podcasting_2_0`            | [bLIP 10](./blip-0010.md)      |
 
 
diff --git a/blip-0014.md b/blip-0014.md
new file mode 100644
index 0000000..9a95374
--- /dev/null
+++ b/blip-0014.md
@@ -0,0 +1,82 @@
+```
+bLIP: 14
+Title: Sender authentication
+Status: Draft
+Author: Joost Jager <joost.jager@gmail.com>
+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 verify 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
\ No newline at end of file