bLIP-04: update from endorsement to accountable signal

README.md

@@ -22,7 +22,7 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
 | [1](./blip-0001.md)      | bLIP Process                    | Ryan Gentry                 | Active |
 | [2](./blip-0002.md)      | Reserved Values                 | Bastien Teinturier          | Active |
 | [3](./blip-0003.md)      | Keysend                         | Valentine Wallace           | Active |
-| [4](./blip-0004.md)      | Experimental Endorsement        | Carla Kirk-Cohen            | Active |
+| [4](./blip-0004.md)      | Experimental Accountability     | Carla Kirk-Cohen            | Active |
 | [10](./blip-0010.md)     | Podcasting 2.0                  | Satoshis Stream             | Active |
 | [11](./blip-0011.md)     | NameDesc                        | Hampus Sjöberg              | Active |
 | [17](./blip-0017.md)     | Hosted Channels                 | Anton Kumaigorodskiy        | Active |

blip-0002.md

@@ -50,7 +50,7 @@ bLIPs may reserve feature bits by adding them to the following table:
 | 54/55   | `keysend`              | A form of spontaneous payment                              | N       | `var_onion_optin`       | [bLIP 3](./blip-0003.md)  |
 | 256/257 | `hosted_channels`      | This node accepts requests for hosted channels             | IN      |                         | [bLIP 17](./blip-0017.md) |
 | 258/259 | `dns_resolver`         | This node accepts DNSSEC proof requests                    | N       |                         | [bLIP 32](./blip-0032.md) |
-| 260/261 | `htlc_endorsement`     | This node forwards experimental htlc endorsement signals   | N       |                         | [bLIP 4](./blip-004.md)   |
+| 260/261 | `htlc_accountability`  | This node forwards experimental htlc accountability signals| N       |                         | [bLIP 4](./blip-004.md)   |
 | 262/263 | `bolt11_blinded_path`  | This invoice may contain a new blinded path tagged field   | I       | `option_route_blinding` | [bLIP 39](./blip-0039.md) |
 | 729     | `option_supports_lsps` | This node supports LSPS protocol(s)                        | IN      |                         | [bLIP 50](./blip-0050.md) |
 
@@ -113,7 +113,7 @@ The following table contains extension tlv fields for the `update_add_htlc` mess
 
 | Type   | Name                        | Link                           |
 |--------|-----------------------------|--------------------------------|
-| 106823 | `endorsed`                  | [bLIP 4](./blip-0004.md)       |
+| 106823 | `accountable`               | [bLIP 4](./blip-0004.md)       |
 | 65537  | `extra_fee`                 | [bLIP 25](./blip-0025.md)      |
 
 #### `ping`

blip-0004.md

@@ -1,19 +1,20 @@
 ```
 bLIP: 4
-Title: Experimental Endorsement Signaling
+Title: Experimental Accountable Signaling
 Status: Active
 Author: Carla Kirk-Cohen <carla@chaincode.com>
+        elnosh <elnosh@pm.me>
 Created: 2024-01-12
 License: CC0
 ```
 
 ## Abstract
 
-HTLC endorsement signaling is a [proposed](https://github.com/lightning/bolts/pull/1071) 
+HTLC accountability signaling is a [proposed](https://github.com/lightning/bolts/pull/1280)
 component of a [hybrid approach](https://research.chaincode.com/2022/11/15/unjamming-lightning) 
 to addressing [channel jamming attacks](https://bitcoinops.org/en/topics/channel-jamming-attacks) 
 against the Lightning Network. This bLIP outlines a proposal to deploy an 
-experimental endorsement TLV to the network to provide real world data to 
+experimental accountable TLV to the network to provide real world data to
 inform specification of reputation algorithms.
 
 ## Copyright
@@ -22,78 +23,57 @@ This bLIP is licensed under the CC0 license.
 
 ## Specification
 
-Experiment Parameters, expressed as unix time (seconds):
-* `experiment_start`: TODO: set once feature bit is widely deployed
-* `experiment_end`: 1767225600
-
 ### Adding an HTLC: `update_add_htlc`:
 
 1. `tlv_stream`: `update_add_htlc_tlvs`
-    1. type: 106823(`endorsed`)
+    1. type: 106823 (`accountable`)
     2. data:
-        * [`byte`:`endorsed`]
+        * [`byte`:`accountable`]
 
-The 3 least significant bits of the endorsement TLV are used to represent an
-endorsement value. A HTLC is considered to be endorsed if it is received
-with `endorsed`=7 and unendorsed if `endorsed=0`.
+The 3 least significant bits of the accountable TLV are used to represent an
+accountability value. A HTLC is considered to be accountable if it is received
+with `accountable=7` and unaccountable if `accountable=0`.
 
 Sender:
-* If the current time is less than `experiment_end`:
-  * if it is the original source of the HTLC:
-    * if the current time is greater than or equal to `experiment_start`:
-      * if it does not expect immediate fulfillment upon receipt by the 
-        final destination: 
-        * SHOULD set `endorsed` to `0`.
-      * otherwise:  
-        * SHOULD set `endorsed` to `7`.
-    * otherwise:
-      * SHOULD set `endorsed` to `0`
-    * MAY choose to set `endorsed` to `0` for some percentage of payments to 
-      prevent leaking its identity as the original sender.
+* if it is the original source of the HTLC:
+  * SHOULD set `accountable` to `0`.
+  * MAY set `accountable` to `7` to mimic observed forwarded traffic.
 
 Receiver:
-* If the current time is less than `experiment_end`:
+* if `accountable`=7 in the incoming `update_add_htlc`:
+    * SHOULD set `accountable` to `7` on its outgoing `update_add_htlc`
+* otherwise:
   * if running an experimental reputation algorithm:
-    * SHOULD set `endorsed` at its discretion.
-  * otherwise: 
-    * if `endorsed`=7 in the incoming `update_add_htlc`:
-        * SHOULD set `endorsed`=7 on its outgoing `update_add_htlc`
-    * otherwise: 
-      * SHOULD set `endorsed` to `0`.
-* MUST NOT use the experimental `endorsed` field in resource allocation 
+    * SHOULD set `accountable` at its discretion.
+  * otherwise:
+    * SHOULD set `accountable` to `0`.
+* MUST NOT use the experimental `accountable` field in resource allocation
   decisions.
 
 ## Deployment and Deprecation
 
-### Deployment 
-
-Forwarding nodes can upgrade and begin to set `endorsed` signals immediately, 
-as there is no privacy risk associated with propagating zero values. Feature 
-bit signaling and a flag day are used to allow senders to set `endorsed` to `7`
-without leaking their identity as the original sender of the HTLC.
+Forwarding nodes can upgrade and begin to set `accountable` signals immediately,
+as there is no privacy risk associated with propagating zero values.
 
 1. Nodes on the network upgrade to support sending and forwarding zero value 
-  `endorsed` signals.
-2. Choose a `experiment_start` parameter based on deployment of the 
-  `htlc_endorsed` signal on the network.
-3. After `experiment_start` has passed, sending nodes start to set `endorsed` 
-   to `7` as described above.
-4. When `experiment_end` is reached, sending node on the network stop setting 
-   the experimental `endorsed` field and intermediate nodes will stop 
-   relaying it, so the signal will cease to propagate through the network.
-
-### Deprecation
-
-If `endorsement` is merged to the BOLTs, the experimental field will naturally 
-be deprecated when `experiment_end` is reached. 
-
-1. Nodes on the network may freely use an endorsement signal defined by the 
-   BOLTs, even if `experiment_end` has not yet been reached, as the experimental 
-   signal described in this bLIP is distinct from one outlined in the BOLTs.
-2. Once `experiment_end` has been reached, all nodes will stop relaying the 
-   experimental signal.
-3. In the next release, experimental code can safely be removed as it has been 
-   deprecated across the network.
+  `accountable` signals.
+2. Nodes running experimental reputation algorithm may set non-zero accountable
+signals.
+3. Signals can be observed in the network to gather data to inform design of
+reputation algorithms.
+
+We only expect nodes running experimental reputation algorithms to set a
+non-zero accountable signal in times of congestion; it will be normal for both
+sending and forwarding nodes to set zero value signals. There is no privacy
+concern for senders setting a zero accountable signal, as this is normal
+behavior for both sending and forwarding nodes.
+
+To deprecate the signal once experimentation is complete:
+
+1. Nodes running experimental reputation algorithms stop setting non-zero
+values.
+2. Remove the `htlc_accountability` feature bit and stop relaying and setting
+the TLV.
 
 ## Motivation
 
@@ -104,38 +84,33 @@ setting so that we can direct further specification in an informed manner.
 
 ## Rationale
 
-Endorsement signals are copied from the incoming `update_add_htlc` to allow 
-positive signals to propagate through the network. Nodes wishing to participate
-in active experimentation may set this signal according to their local 
-reputation algorithm, and this signal will be passively propagated by the 
-upgraded portion of the route. This experimental signal is used to observe 
-the behavior of reputation algorithms under real-world conditions, but is not 
-used to allocate resources so that the experiment does not impact payment 
+Positive accountability signals are copied from the incoming `update_add_htlc`
+to allow signals to propagate through the network. Nodes wishing to participate
+in active experimentation may set this signal according to their local
+reputation algorithm, and this signal will be passively propagated by the
+upgraded portion of the route. This experimental signal is used to observe
+the behavior of reputation algorithms under real-world conditions, but is not
+used to allocate resources so that the experiment does not impact payment
 traffic.
 
-A flag day is included to mitigate privacy concerns that setting the 
-endorsement signal on payments will expose the identity of the original sender.
-Nodes participating in the experiment will signal the `htlc_endorsed` feature 
-in their node announcement to help chose an appropriate `experiment_start`. 
-Once a sufficient portion of the network is upgraded to relay these signals, the 
-presence of positive endorsement does not expose the sender as the original 
-source of the HTLC. Senders are also advised to only set a positive endorsement
-signal for some percentage of payments to further protect sender privacy.
-
-The `endorsed` TLV is encoded as a single `byte` rather than a boolean to allow
-flexible experimentation. Three bits of information are used to represent 
-endorsement to allow for the future possibility of experimentation that relies 
-on a range of endorsement values. HTLCs that are not endorsed include a TLV 
-with a zero value byte so that they can be distinguished from those with no 
-endorsement signal, which can be filtered out of experimental data as null 
-values.
+HTLCs that are not accountable include a TLV with a zero value byte so that
+they can be distinguished from those with no accountability signal, which can
+be filtered out of experimental data as null values.
+
+**Note: Previously we allowed a range for the `accountable` signal as it was
+used to signal endorsement of an HTLC. This endorsement could be interpreted
+as the level of trust in the upstream node and the HTLC resolving in time.
+Hence, we allowed a range to allow experimenting with different values. This
+signal has been repurposed (since it is an experimental read-only field) to
+now indicate accountability, which is a binary decision letting the downstream
+node know if it will be held accountable for the fast resolution of the HTLC.**
 
 This experiment is opened as a bLIP because it is not intended to be a 
-permanent part of the lightning specification. If a BOLT with endorsement 
+permanent part of the lightning specification. If a BOLT with accountability
 signaling is merged to the BOLTs, the two signals can be handled independently 
 and the experimental signal described in this bLIP can be removed after the 
 end of the experimental period.
 
 ## Reference Implementations
 
-* [LND](https://github.com/lightningnetwork/lnd/pull/8390)
+* TODO