blip-0004: experimental endorsement signaling in update_add_htlc

[carlaKC]

bLIP 0004 for experimental endorsement signalling:

• Adds TLV number 65555 to update_add_htlc for experimental endorsement signaling
• Provides instructions for relaying this signal after a flag day

[t-bast]

ACK, @thomash-acinq does that work for you?

[TheBlueMatt]

A bit weird we have a BLIP reserving a value for a BOLT PR - do we want to include like a timeout on this reservation - "just for testing, after date X this is returned to the available pool"?

[carlaKC]

A bit weird we have a BLIP reserving a value for a BOLT PR

Yeah .. there just isn't really a better place for reserving the value.

do we want to include like a timeout on this reservation - "just for testing, after date X this is returned to the available pool"?

Can't we just come back and deprecate it once we're done? Because hard setting a date required that folks are upgraded to stop using it by then? Not like we're short of TLV types.

[carlaKC]

As I understand the line between BLIPs/BOLTS, this is the wrong place for the TLV reservation (because this is something that we intend to deploy to the whole network, so it's a BOLT), so I'd be hesitant to continue further down the BLIP path. I opened this just to flag that the TLV field is being used somewhere public, I'm not sure it even needs merging tbh.

Actually, now that I think about it, what's stopping us from placing the HTLC Endorsement inside the BLIP and then deprecating the BLIP itself?

For example - I could copy the text in, but then would we do a review round on the BLIP and the BOLT? Seems messy.

[vincenzopalazzo]

For example - I could copy the text in, but then would we do a review round on the BLIP and the BOLT? Seems messy.

Well before all we should decide for what we want to use the BLIPs repository and for what we want to use the BOLT one.

as I see, the jamming research can be a BLIP without touch the BOLT, but this is just my feeling, and I my understand wrong the scope of the BLIPs

[carlaKC]

Updated to include Antione's suggestion of including a deprecation_flag_day and @ProofOfKeags suggested rewording for setting endorsement values when actively participating.

[PurpleTimez]

SGTM.

[carlaKC]

Seems like everyone is happy to go ahead with 3 bits of information. While we certainly could bikeshed a more complex scheme, I think that this is good enough for our purposes and strikes a good balance of:

• Allowing experiments to opt into the full 3 bits
• By default relaying min/max values (effectively true/false) so that the signal propagates through the network without "step down" privacy concerns

@ProofOfKeags @thomash-acinq @vincenzopalazzo anything outstanding on your end?

Last on my end is picking dates, WDYT about:

• Leave experiment_start as a TODO when we merge, as it depends on deployment of the experimental flag
• Set experiment_end to 31 December 2026

[carlaKC]

Updated to set experiment_end and chose a more random TLV value (per bolt 01).

[carlaKC]

Thanks again for the reviews! Addressed last few nits/clarifications - I think this is ready to go 🚀

[carlaKC]

Rebased + updated feature bit to not clash with dns_resolver

[carlaKC]

Summary of discussion from today's call:

• We'll leave the instructions as-is for interpretation of values: just strictly defining the edges of the range (7=endorsed / 0=unendorsed) in the blip
• @thomash-acinq will run the numbers with their algo to give a reasonable threshold for interpretation based on existing data (eg: consider >6 endorsed) which I'll use in my impl
• By default only forward as endorsed if endorsed=7, otherwise set endorsed=0 to prevent any privacy leaks (ofc impls can do what they want, because the node operator is opting in to that)

[carlaKC]

Can we go ahead and merge this @t-bast / @thomash-acinq?

It's been sitting for a while and is starting to run into feature bit conflicts.

[t-bast]

Sounds good to me, we've added support for this to eclair (https://github.com/ACINQ/eclair/pull/2884) so let's get this merged!