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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
