Hi all, Everywhere in the protocol where we negotiate, we've had problems: what do you do if you can't agree? In most cases, we've settled on defacto generally-accepted values which aren't mentioned anywhere in the spec (I've skimmed codebases below, looked at defaults). I'd like to re-examine these in light of our real-life experience and see if we can simplify them, or at least make suggestions:

funding_satoshis ---------------- c-lightning: must be >= 1000 (after reserve subtracted) Eclair: must be >= 100000 lnd: any SUGGESTION: At 253 satoshi/kSipa, and dust at 546, 1000 is too low to be sane (one output would always be dust). Eclair seems pessimistic though; Should we suggest that any channel under 3 x min(our_dust_limit, their_dust_limit) SHOULD be rejected as too small (ie. min is 546*3). dust_limit_satoshis ------------------- c-lightning: gives 546, accepts any. Eclair: gives 546 (configurable), accepts >= 546. lnd: gives 573, accepts any. (Note: eclair's check here is overzealous, but friendly). SUGGESTION: we have to make this variable in future anyway (IRL it depends on min_relay_fee, which in turn depends on backlog...). I'd love to just pick a number :( max_htlc_value_in_flight_msat ----------------------------- c-lightning: gives U64_MAX, accepts >= 1000000. Eclair: gives 5000000000, accepts any. lnd: gives capacity - reserve, accepts >= 5 * htlc_minimum_msat. SUGGESTION: maybe drop it (must be U64_MAX?). channel_reserve_satoshis ------------------------ c-lightning: gives 1% (rounded down), accepts <= capacity - 1000000. Eclair: gives 1% (?), accepts <= 5% (configurable) lnd: gives 1%, accepts <= 20% SUGGESTION: require it be 1% (rounded down). htlc_minimum_msat ----------------- c-lightning: gives 0, accepts up to 0.1% of channel capacity. Eclair: gives 1, accepts any. lnd: gives 1000, accepts any. SUGGESTION: maybe drop it (ie. must be 0?) to_self_delay ------------- c-lightning: gives 144, accepts <= 2016 Eclair: gives 144, accepts <= 2000 lnd: gives 144-2016 (proportional to funding), accepts <= 10000 SUGGESTION: require it to be <= 2016. Weaker suggestion: make it 2016, or use lnd's proportional formula. max_accepted_htlcs ------------------ c-lightning: gives 483, accepts > 0. Eclair: gives 30, accepts any. lnd: gives 483, accepts >= 5 SUGGESTION: not sure why Eclair limits. Maybe make it 483? minimum_depth ------------- c-lightning: gives 3, accepts <= 10. Eclair: gives 3, accepts any. lnd: gives 3-6 (scaling with funding), accepts any. SUGGESTION: This field is only a suggestion anyway; you can always wait longer before sending funding_locked. Let's limit it to <= 6? Are there any other areas of hidden consensus should illuminate and may simplify? Thanks! Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev