[c-lightning] Development priorities for 0.6?

[ZmnSCPxj]

Good morning,

I suggest the below for 0.6 (in addition to items already marked 0.6):

#246 Implement DNS based node lookup and bootstrapping
Because spec.
This is currently marked as 0.6.1 but an existing 0.6 issue (#547) requires this as the second item in its 2-item list, so maybe promote to 0.6?

#387 JSON parse chokes on escaped quotes in strings
#607 Handle escaping in JSONRPC parser and CLI client
Because unexpected behavior.

#475 Speed up channel opening via CPFP+RBF
I think we should consider the case for speeding up channel opening when congestion on blockchain layer exists.

#605 initial_commit_tx can create a 0-output tx without errors
#632 Empty close transaction on very low value channels
I believe a recent BOLT change fixed this, so we should follow BOLT spec and probably assert on these.

#622 `close` should reveal full tx hex, or txid, like `fundchannel`
#714 closing a channel should output more info
For voyeurism
(this seems to not be that easy, though....?)

#665 fund channel with all available funds, or a specific output
Seems useful; we already have a `withdraw all`, why not a `fundchannel all`?
Also maybe add a `withdraw txid:outnum`/`fundchannel txid:outnum`?

#711 Ability to delete all expired invoices at once
Seems simple and useful enough.

#779 Lightning_ processes go <defunct> on startup of daemon
Should not be happening I think...

#812 Ability to disconnect with a peer
Seems simple and useful enough.

#978 old channeld process laying around? (reopen)
Should not be happening I think...

#1042 Put node alias and other human readable things in listpeers
Seems simple and useful enough.

#1086 Add delay limit to `pay`
Limits lockup of funds in case of first hop of a route crashing

#1088 Better feedback when `pay` takes long
Quite a few recent issues involve users being surprised by our payment algorithm and getting confused about what we are doing.
Better feedback is definitely needed when pay does things.
I would suggest building asynchronous `pay` command in the daemon, and also install a lightning-pay executable that wraps the RPC commands for this so that it can report continuously on what we are doing.

Regards,
ZmnSCPxj


​Sent with ProtonMail Secure Email.​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On February 26, 2018 11:29 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hi all!
> 
> We've been far too long between releases: I am going to stop
> 
> doing enhancements and new features and concentrate on the issue backlog
> 
> with the aim to getting a 0.6.0 release out as soon as possible. First
> 
> step is to tag everything appropriately.
> 
> I think we'll go for a -pre1... -preN, then -rc1 .. rcN. We'll
> 
> remove currently deprecated options just before -pre1 (the normal
> 
> practice will be to remove just after release, but IMHO it's too early
> 
> to carry baggage for long).
> 
> After 0.6, we would start to care more about backwards
> 
> compatibility (eg. testing database upgrades!), and hopefully have fewer
> 
> times when we tell people SFYL.
> 
> My priorities for 0.7 will be testing, testing, testing. We'll
> 
> also want to add support for new feature bits, but our technical debt on
> 
> protocol-level testing has grown large, and some independent test suites
> 
> will be a great addition for all implementations. We may release a
> 
> 0.6.1 etc, but I'm not sure if we'd branch for that, or just roll
> 
> forwards.
> 
> Cheers!
> 
> Rusty.
> 
> 
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> c-lightning mailing list
> 
> c-lightning at lists.ozlabs.org
> 
> https://lists.ozlabs.org/listinfo/c-lightning