DataSig: Signing data over lightning payments

blip-0012.md

@@ -0,0 +1,103 @@
+```
+bLIP: 12
+Title: DataSig
+Status: Draft
+Authors: George Tsagkarelis <[email protected]>
+         Aristoteles Panaras <[email protected]>
+Created: WIP
+License: CC0
+```
+
+# Abstract
+
+The scope of this proposal is transmitting data over the Lightning
+Network by utilizing custom TLV records carried to the destination by lightning payments.
+
+This way of communication enforces two main restrictions:
+
+1. Each transmission has a relatively small maximum size, which is
+the remaining space of the [onion packet structure](https://github.com/lightning/bolts/blob/master/04-onion-routing.md#packet-structure) used for routing the payment.
+
+2. Each transmission's data require a lightning payment to get carried, meaning
+that a very small amount of msat will have to be burned for the data to reach the destination.
+
+The receiver of such transmissions is highly encouraged to have keysend([blip-003](https://github.com/lightning/blips/blob/master/blip-0003.md)) enabled, as that allows for the sender to spontaneously execute the data  transmission.
+
+Many use-cases that utilize such data transmissions may need to verify that the data included in the transmission were **authored** (and possibly sent[^1]) by a specific node in the network and were **meant to be sent** to a specific destination.
+
+
+# Specification
+
+This spec's aim is to describe the format of a structure representing
+a signature over some arbitrary data.
+
+Before proceeding, a few clarifications must be made:
+  * The data are placed inside a custom TLV record.
+  * The DataSig structure is placed inside another custom TLV record of the payment carrying the data.
+  * DataSig allows the receiving end validate that:
+    * Data were authored by the source node
+    * Data were meant to be received by the receiving node.
+
+
+We consider a compact encoding to be used for representing the
+DataSig structure over a TLV, so it is expressed as the following
+protobuf message:
+
+```protobuf
+message DataSig {
+  uint32 version = 1;
+  bytes sig      = 2;
+  bytes senderPK = 3;
+}
+```
+
+* `version`: The version of DataSig spec used.
+* `sig`: The bytes of the signature.
+* `senderPK`: The sender's public key.
+
+## Generation
+
+In order to instantiate a DataSig signing the data `D`, sending node needs
+to follow these steps:
+
+1. Populate `version` with the version that is going to be used.
+2. Prepend the desired destination address (`A`) to `D`,
+   creating a new byte array (`AD`).
+3. Sign the byte array `AD`, generating a signature encoded in
+   fixed-size LN wire format.
+4. Populate the `sig` field with the generated signature.
+5. Populate `senderPK` with own address.
+6. Encode the resulting DataSig structure to wire format according to protobuf definition (byte array `S`).
+
+## Verification
+
+Assuming that the destination node has retrieved:
+  * The byte array of the data `D`
+  * The byte array of the encoded signature struct `S`
+
+The data should be verified against the signature
+by following the below procedure:
+
+1. Decode bytes `S` according to DataSig protobuf message definition.
+2. If signature `version` is not supported or unknown, consider data
+   to be unsigned.
+3. Prepend own address (`A`) to byte array `D`, generating the byte
+   array `AD`.
+4. Verify the signature provided in `sig` field against the message
+   `AD` and sender public key `senderPK`.
+
+# Rationale
+
+Node to node communication over the Lightning Network is a utility that enables many new use cases which may greatly improve the financial relation between nodes but also enable many new applications that can run directly p2p without exiting the network.
+
+Transmitting data over lightning payments is a way of direct node communication currently supported by all major implementations.
+
+Communicating over payments also inherits the incentive model of payments for data transmissions. Each routing node gets direct compensation for forwarding some data through the  base fee. Also, data transmissions are indistinguishable from payments, from the routing node perspective, as they actually **are** payments.
+
+The operation of forwarding data over a lightning payment has an extra resource cost, as this involves a handful of HTLCs to be updated over the route. This way of messaging does not fit high bandwidth communications as it is restricted by low network throughput and a tangible financial cost.
+
+# Notes / Remarks
+
+* In this specification we do not define which TLV keys should be used for the data and the DataSig structure. Since many applications may be used over a single lightning node it is useful to allow separation of traffic by each application utilizing their own TLV keys.
+
+[^1]: It is not safe to assume by receiving a payment carrying some data and a valid signature that the node which initiated the payment was the author of the data. It is possible (intentionally or not) for the authoring node to hand over the DataStruct record and the data record to a 3rd node, which can fire payments towards the intended receiver.