Carla Kirk-Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-01 🗒️ Summary of this message: The plan is to ...
📅 Original date posted:2023-08-01
🗒️ Summary of this message: The plan is to collect data on HTLC endorsement and local reputation tracking to mitigate jamming attacks. Multiple teams are involved in different phases of the plan.
📝 Original message:
Hi list,
## TL;DR
We're moving ahead with the plan discussed at the summit to "dry run"
HTLC endorsement and local reputation tracking to better inform our
efforts to mitigate jamming attacks.
Our goals are:
* To use real-world data to sanity check the "steady state" behavior
of local reputation algorithms, and to better inform creation of
synthetic data for simulating attack scenarios.
* To obtain liquidity and slot utilization data to inform sane defaults
for resource bucketing.
* To provide a common data export format to use as a common basis for
analysis.
As code takes some time to write and deploy, there are a few phases
for this plan - details at the end of the email for those who are
interested!
1. Collect anonymized forwarding data with a common format.
2. Propagate experimental `endorsement` TLV.
3. Implement local reputation and set `endorsement` values.
This is a multi-team effort:
* Eclair: Thomas is looking into collecting local reputation data
in [1].
* CLN: Vincenzo is working on experimental update to propagate the
endorsement field and a plugin that will allow us to run local
reputation scoring.
* LND: I am working on data export and HTLC endorsement via
circuitbreaker [2].
* LDK: some additional plumbing is needed, as outlined in [3].
## Research Plan
### 1. Collect Anonymized Data
We're aware that we are dealing with sensitive and private information.
For this reason, we propose defining a common data format so that
analysis tooling can be built around, so that node operators can run
the analysis locally if desired. Fields marked with [P] *MUST* be
randomized if exported to researching teams.
The proposed format is a CSV file with the following fields:
* version (uint8): set to 1, included to future-proof ourselves
against the need to change this format.
* channel_in (uint64)[P]: the short channel ID of the incoming channel
that forwarded the HLTC.
* channel_out (uint64)[P]: the short channel ID of the outgoing
channel that forwarded the HTLC.
* peer_in (hex string)[P]: the hex encoded pubkey of the remote peer
for the channel_in.
* peer_out (hex_string)[P]: the hex encoded pubkey of the remote peer
for the channel_out.
* fee_msat(uint64): the fee offered by the HTLC, expressed in msat.
* outgoing_liquidity (float64): the portion of
`max_htlc_value_in_flight` that is occupied on channel_out after the
HTLC has been forwarded.
* outgoing_slots (float64): the portion of `max_accepted_htlcs` that
is occupied on channel_out after the HTLC has been forwarded.
* ts_added_ns (uint64): the unix timestamp that the HTLC was added,
expressed in nanoseconds.
* ts_removed_ns (uint64): the unix timestamp that the HLTC was
removed, expressed in nanoseconds.
* htlc_settled (bool): set to 0 if the HTLC failed, and 1 if it was
settled.
* incoming_endorsed (int16): an integer indicating the endorsement
status of the incoming HTLC (-1 if not present, otherwise set to the
value in the incoming endorsement TLV).
* outgoing_endorsed (int16): an integer indicating the endorsement
status of the outgoing HTLC (-1 if not set, otherwise set to the
value set in the outgoing endorsement TLV).
Before we add endorsement signaling and setting via an experimental
TLV, the last two values here will always be -1. The data is still
incredibly useful in the meantime, and allows for easy update once the
TLV is propagated through the network.
### 2. Propagate Experimental Endorsement TLV
HTLC endorsement is signaled using an experimental range TLV in
`update_add_htlc` (which has been reserved in [4]):
tlv_stream: update_add_htlc_tlvs
Type: 655555
Data: byte (endorsed)
This signal should be propagated by forwarding nodes in the following
manner:
- if `endorsed` is present in the incoming `update_add_htlc`:
- set the same value for the outgoing `update_add_htlc`.
- otherwise:
- set `endorsed` = 0 for the outgoing `update_add_htlc`.
### 3. Implement Local Reputation and Set Endorsement
The final step will be to implement local reputation algorithms and
start to actively set the value of the `endorsed` TLV for outgoing
HTLCs, rather than simply copying the value presented by the sending
node. This signal will *not* be used for any purpose other than
data collection.
Experimenters are free to use the full range of bits to express
endorsement values, but should be aware that any non-zero value will
be interpreted as a positive endorsement signal by implementations
using binary endorsement (as is currently specified in [5]).
A positive endorsement signal requires that the original sender of a
HTLC sets a non-zero value, but bears the privacy risk of indicating
that they are the sending node during upgrade. We suggest that senders
choose some probability P (suggested default: 20%) with which to set
endorsed=1 for their payments.
Once we've got data collection code in place, we'll make a more
general call for node operators to start collection. In the meantime,
feel free to reach out if you have any questions or are interested in
helping out!
Cheers,
Carla + Clara
## References
[1] https://github.com/ACINQ/eclair/pull/2716
[2] https://github.com/lightningequipment/circuitbreaker/issues/77
[3] https://github.com/lightningdevkit/rust-lightning/issues/2425
[4] https://github.com/lightning/blips/pull/27
[5] https://github.com/lightning/bolts/pull/1071
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230801/9ef1baa2/attachment-0001.html>;
🗒️ Summary of this message: The plan is to collect data on HTLC endorsement and local reputation tracking to mitigate jamming attacks. Multiple teams are involved in different phases of the plan.
📝 Original message:
Hi list,
## TL;DR
We're moving ahead with the plan discussed at the summit to "dry run"
HTLC endorsement and local reputation tracking to better inform our
efforts to mitigate jamming attacks.
Our goals are:
* To use real-world data to sanity check the "steady state" behavior
of local reputation algorithms, and to better inform creation of
synthetic data for simulating attack scenarios.
* To obtain liquidity and slot utilization data to inform sane defaults
for resource bucketing.
* To provide a common data export format to use as a common basis for
analysis.
As code takes some time to write and deploy, there are a few phases
for this plan - details at the end of the email for those who are
interested!
1. Collect anonymized forwarding data with a common format.
2. Propagate experimental `endorsement` TLV.
3. Implement local reputation and set `endorsement` values.
This is a multi-team effort:
* Eclair: Thomas is looking into collecting local reputation data
in [1].
* CLN: Vincenzo is working on experimental update to propagate the
endorsement field and a plugin that will allow us to run local
reputation scoring.
* LND: I am working on data export and HTLC endorsement via
circuitbreaker [2].
* LDK: some additional plumbing is needed, as outlined in [3].
## Research Plan
### 1. Collect Anonymized Data
We're aware that we are dealing with sensitive and private information.
For this reason, we propose defining a common data format so that
analysis tooling can be built around, so that node operators can run
the analysis locally if desired. Fields marked with [P] *MUST* be
randomized if exported to researching teams.
The proposed format is a CSV file with the following fields:
* version (uint8): set to 1, included to future-proof ourselves
against the need to change this format.
* channel_in (uint64)[P]: the short channel ID of the incoming channel
that forwarded the HLTC.
* channel_out (uint64)[P]: the short channel ID of the outgoing
channel that forwarded the HTLC.
* peer_in (hex string)[P]: the hex encoded pubkey of the remote peer
for the channel_in.
* peer_out (hex_string)[P]: the hex encoded pubkey of the remote peer
for the channel_out.
* fee_msat(uint64): the fee offered by the HTLC, expressed in msat.
* outgoing_liquidity (float64): the portion of
`max_htlc_value_in_flight` that is occupied on channel_out after the
HTLC has been forwarded.
* outgoing_slots (float64): the portion of `max_accepted_htlcs` that
is occupied on channel_out after the HTLC has been forwarded.
* ts_added_ns (uint64): the unix timestamp that the HTLC was added,
expressed in nanoseconds.
* ts_removed_ns (uint64): the unix timestamp that the HLTC was
removed, expressed in nanoseconds.
* htlc_settled (bool): set to 0 if the HTLC failed, and 1 if it was
settled.
* incoming_endorsed (int16): an integer indicating the endorsement
status of the incoming HTLC (-1 if not present, otherwise set to the
value in the incoming endorsement TLV).
* outgoing_endorsed (int16): an integer indicating the endorsement
status of the outgoing HTLC (-1 if not set, otherwise set to the
value set in the outgoing endorsement TLV).
Before we add endorsement signaling and setting via an experimental
TLV, the last two values here will always be -1. The data is still
incredibly useful in the meantime, and allows for easy update once the
TLV is propagated through the network.
### 2. Propagate Experimental Endorsement TLV
HTLC endorsement is signaled using an experimental range TLV in
`update_add_htlc` (which has been reserved in [4]):
tlv_stream: update_add_htlc_tlvs
Type: 655555
Data: byte (endorsed)
This signal should be propagated by forwarding nodes in the following
manner:
- if `endorsed` is present in the incoming `update_add_htlc`:
- set the same value for the outgoing `update_add_htlc`.
- otherwise:
- set `endorsed` = 0 for the outgoing `update_add_htlc`.
### 3. Implement Local Reputation and Set Endorsement
The final step will be to implement local reputation algorithms and
start to actively set the value of the `endorsed` TLV for outgoing
HTLCs, rather than simply copying the value presented by the sending
node. This signal will *not* be used for any purpose other than
data collection.
Experimenters are free to use the full range of bits to express
endorsement values, but should be aware that any non-zero value will
be interpreted as a positive endorsement signal by implementations
using binary endorsement (as is currently specified in [5]).
A positive endorsement signal requires that the original sender of a
HTLC sets a non-zero value, but bears the privacy risk of indicating
that they are the sending node during upgrade. We suggest that senders
choose some probability P (suggested default: 20%) with which to set
endorsed=1 for their payments.
Once we've got data collection code in place, we'll make a more
general call for node operators to start collection. In the meantime,
feel free to reach out if you have any questions or are interested in
helping out!
Cheers,
Carla + Clara
## References
[1] https://github.com/ACINQ/eclair/pull/2716
[2] https://github.com/lightningequipment/circuitbreaker/issues/77
[3] https://github.com/lightningdevkit/rust-lightning/issues/2425
[4] https://github.com/lightning/blips/pull/27
[5] https://github.com/lightning/bolts/pull/1071
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230801/9ef1baa2/attachment-0001.html>;