Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-17 📝 Original message: Hi all, Everywhere in the ...

📅 Original date posted:2018-10-17
📝 Original message:
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.