[c-lightning] Feature freeze in preparation for 0.6?
decker.christian at gmail.com
Mon Apr 30 22:53:22 AEST 2018
thanks Rusty for taking the lead on this, we definitely should do a 0.6
release as soon as possible. I took the opportunity and went through the
issue list, marking some as stale and closing others that are fixed or
can't be reproduced with today's code. So here are the things that I
think need to be part of the feature freeze, on top of what Rusty and
ZmnSCPxj already mentioned:
- I'd like to bump some of our default parameters to at least make them
compatible with the default params that lnd and eclair use. The following
need to be adjusted:
- Bump the `our_unilateral_close/to_us` maximum value to 2016. This'll hurt a
bit since most closes are currently uncooperative and waiting 2 weeks
instead of 1 day is bad, but Roasbeef assured me that they will slowly
decrease this as the system stabilizes and watch-tower designs are
implemented. This would sort of address #1110, in exchange for angry users
with locked in funds...
- Bump the default `cltv_delta` to 8, since eclair is enforcing that as a
minimum for the last hop currently. They mentioned removing that
enforcement on the sender side, but current deployed wallets seem to still
- To reduce the number of unilateral closes we should accept a fee update that
is outside of our range, but then close the channel collaboratively instead
of slamming the door (paying the on-chain fees and having to wait an
eternity). I just filed this as #1443.
- We sometimes get into a situation in which the remote end doesn't send its
`announcement_signature` upon reconnecting. Not sure if this is our fault or
an incompatibility with another implementation. I'm tempted to just send it
on every reconnect if we have reached `announce_depth`.
- #551 seems important but unlikely to cause much trouble at first, if we can
fix it good.
- We need to change the DEVELOPER=1 to DEVELOPER=0 by default. `dev-xyz` RPC
calls and options should only ever be used in a debugging scenario.
- Of course all fixes that address a crash are definitely in-scope, but
shouldn't be blocking the release if they're "rare"
And now for the list of things we should not try to squeeze into the 0.6
- Fee related fixes are probably out of scope and will need some additional
work (#613, #666, #750, #1219, #1233)
- Pruning support. This has gotten a lot better since we no longer rescan from
the wallet birth, but if the sync horizon of c-lightning is being pruned,
e.g., prolonged downtime, it'll still get stuck and we need an alternative
source for the pruned blocks (maybe the Bitcoin P2P network?).
Most of these are rather small changes, but especially bumping the default
params may be controversial, which is why I'm not opening a PR just yet. Of
course all of these are up for debate :-)
More information about the c-lightning