[c-lightning] Development priorities for 0.6?

Wed Feb 28 02:10:23 AEDT 2018

I think we are pretty close to feature complete already, but there are a
few things we won't be able to change too much after a release:

 - We should probably do another pass over the JSON-RPC and see that
   it's future proof
 - We definitely need to make DEVELOPER=0 the default config, so that
   issues like `dev-setfees 0` don't happen

As for specific issues, I think critical ones are:

 - JSON parse chokes on escaped quotes in strings #387
 - Track owned outputs when they are being spent on the blockchain #451
 - Empty close transaction on very low value channels #632
 - Implement DNS based node lookup and bootstrapping #246
 - Ability to disconnect with a peer #812

I was deferring the implementation of DNS lookups for seeds since we
don't yet have async name resolution, but I saw that we do sync in some
cases, so I could just rely on that as well for now.

My WIP PR #1117 should also get rid of the need for `dev-rescan-outputs`
so we can keep that a developer-only call, and it fixes #451.

Shall we go through the issues and just assign them to v0.6?

Cheers,
Christian

ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> 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
>
>
> -- 
> c-lightning mailing list
> c-lightning at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/c-lightning