[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

Pierre pm+lists at acinq.fr
Wed Nov 7 04:51:21 UTC 2018


Hi Rusty,

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

The rationale for a relatively high minimal funding_satoshi is to not
have tons of
unilateral channel closings when there is a network fee spike. We
still care as a fundee,
because we may have a positive balance and will be annoyed if our
funds are delayed.

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

The reasoning is that we do care about remote's commitment tx
dust_limit in a dataloss
recovery scenario.

>
> 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 :(

Me too!

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

Agreed.

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

Agreed.

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

Why not, given that relay fees make it non-free anyway.

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

2016 is sooo long though ;-) Especially given the high number of
unilateral close
we still see on mainnet. How about <= 1008?


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

We wanted to avoid having a huge commitment tx and a corresponding
network fee. Since
the funder pays the fee, there is a loose connection between this,
funding_satoshis and
htlc_minimum_msat.

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

I'm fine with <= 6, but as someone else noted, this would be Bitcoin specific.

> Are there any other areas of hidden consensus should illuminate and may
> simplify?

The two obvious ones are "who should force close when an error happens" and
"what is the current feerate" but both are being handled in the new commitment
format proposal.

I think we should also reconsider the hardcoded maximum funding_satoshis (maybe
dig up the "dangerous" flag proposal?).


More information about the Lightning-dev mailing list