Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

blip-0004: experimental endorsement signaling in update_add_htlc #27

Merged
merged 1 commit into from
Aug 8, 2024
Merged

blip-0004: experimental endorsement signaling in update_add_htlc #27

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,10 @@ 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 |
| [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 |
| [25](./blip-0025.md) | Forward less than onion value | Valentine Wallace | Active |
| [32](./blip-0032.md) | Onion Message DNS Resolution | Matt Corallo | Active |

19 changes: 14 additions & 5 deletions blip-0002.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,11 +45,12 @@ Custom feature bits used in the `I` [Bolt 11](https://github.com/lightning/bolts

bLIPs may reserve feature bits by adding them to the following table:

| Bits | Name | Description | Context | Dependencies | Link |
| --------- | ---------------------- | ------------------------------------------------- | ---------------- | -------------------------------- | -------------------------------- |
| 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) |
| Bits | Name | Description | Context | Dependencies | Link |
| --------- | ---------------------- | ----------------------------------------------------------- | ---------------- | -------------------------------- | -------------------------------- |
| 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) |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced that it's useful to advertise this feature. Nodes that don't support it will just ignore the endorsement value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Advertising the feature allows us to get an idea of when we should start setting non-zero values as a sender. If we don't have this feature and senders start setting a positive endorsed signal and nobody is relaying yet, we trivially expose them as the sender.


### Messages

Expand Down Expand Up @@ -128,6 +129,14 @@ The following table contains tlv fields for use in onion messages as the payload
| 65536 | `dnssec_query` | [bLIP 32](./blip-0032.md) |
| 65538 | `dnssec_proof` | [bLIP 32](./blip-0032.md) |

#### `update_add_htlc`

The following table contains extension tlv fields for the `update_add_htlc` message:

| Type | Name | Link |
|--------|-----------------------------|--------------------------------|
| 106823 | `endorsed` | [bLIP 4](./blip-0004.md) |

## Copyright

This bLIP is licensed under the CC0 license.
141 changes: 141 additions & 0 deletions blip-0004.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,141 @@
```
bLIP: 4
Title: Experimental Endorsement Signaling
Status: Active
Author: Carla Kirk-Cohen <[email protected]>
Created: 2024-01-12
License: CC0
```

## Abstract

HTLC endorsement signaling is a [proposed](https://github.com/lightning/bolts/pull/1071)
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
inform specification of reputation algorithms.

## Copyright

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`)
2. data:
* [`byte`:`endorsed`]

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`.

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.

Receiver:
* If the current time is less than `experiment_end`:
* 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`.
Comment on lines +59 to +62
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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`.
* SHOULD copy `endorsed` from the incoming `update_add_htlc` to the outgoing one.

But who is going to support the endorsed TLV and not run a reputation algorithm?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LND won't ship a reputation algorithm, just the basic mechanics to relay the signal. The reputation algorithm will be implemented externally using its interceptor APIs, and people can opt-in to running it.

I imagine a similar things will be true for CLN - ship basic mechanic by default and then add reputation as a plugin? cc: @vincenzopalazzo?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both Eclair and LDK have an architecture modular enough to add a reputation algorithm as an opt-in external module, Eclair has already a plugin interface (Plugin.scala) and LDK could have a runtime crate catching endorsed-supporting HTLCIntercepted event.

Usually, spec doesn't say how any feature should be supported at the node architecture-level, though here there would be a point to recommend the reputation algorithm to be an external process. If there is a DoS bug in the algorithm, it won't bring down the more safety primordial mechanisms of a LN node, e.g transactions broadcast.

Copy link

@thomash-acinq thomash-acinq Jul 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, thinking more about it I think it's a bad idea to copy the endorsement value if you don't run a reputation algorithm. If you copy blindly the incoming endorsement value, attackers will run their attacks through your node to use your reputation instead of theirs.
If you don't assign reputation to your peers, just always set endorsed to the same constant value regardless of the incomming endorsed, or don't set it at all.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is not as simple as this. This is correct that an attacker can use another lightning node through which a jamming HTLC flow can be circulated, predicting that the endorsed value will be blindly copied to the outgoing HTLC.

On the other hand, a lightning node can have paid out-of-band fees to get inbound liquidity from said lightning
node forwarding a HTLC, and as such there is already a cost for whatever of the jamming on downstream channels.

Dropping out the incoming endorsed field or setting to a constant value will lead to an information loss on the outgoing HTLC flow, and in function of hypothetical reputation algorithms run by downstream channels not have the full benefit of the hypothetical reputation reward of routing "economically honest" HTLCs.

I think following this recommendation of dropping on the floor the endorsed field of incoming HTLC will introduce a bias at the detriment of "economically honest" lightning node, and this independently of channel topology considerations, when I think this blip goals aims solely to introduce minimal experimental protocol fields to allow measurements.

Copy link
Contributor Author

@carlaKC carlaKC Jul 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you copy blindly the incoming endorsement value, attackers will run their attacks through your node to use your reputation instead of theirs.

This BLIP is for a read-only experimental field that allows us to see how reputation algorithms do in the wild. Nobody should be making routing decisions based on this information (MUST NOT use the experimental endorsed field in resource allocation decisions.), so this isn't an issue.

If you don't assign reputation to your peers, just always set endorsed to the same constant value regardless of the incomming endorsed, or don't set it at all.

Certainly agree for when we add a real endorsement signal to the bolts.

I'm assuming that only a small number of nodes will actually run data collection/reputation algorithms for us. If the default behavior is to drop this signal, it'll be a pretty useless experiment.

* MUST NOT use the experimental `endorsed` 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.

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.

## Motivation

The emergent properties of network-wide changes to Lightning are difficult to
fully grasp without gathering real world data. This bLIP outlines a lightweight
and reversible mechanism to assess various reputation algorithms in a read-only
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
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.

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
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)