From pm+lists at acinq.fr Wed Nov 7 04:51:21 2018 From: pm+lists at acinq.fr (Pierre) Date: Wed, 7 Nov 2018 05:51:21 +0100 Subject: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits. In-Reply-To: <878t2xfe9q.fsf@rustcorp.com.au> References: <878t2xfe9q.fsf@rustcorp.com.au> Message-ID: 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?).