From rusty at rustcorp.com.au  Wed Oct 17 03:22:41 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 17 Oct 2018 13:52:41 +1030
Subject: [Lightning-dev] RFC: simplifications and suggestions on open/accept
	limits.
Message-ID: <878t2xfe9q.fsf@rustcorp.com.au>

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.