[c-lightning] Feature freeze in preparation for 0.6?
rusty at rustcorp.com.au
Sat May 5 09:52:13 AEST 2018
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good mornig Rusty,
> Starting a feature freeze is fine, it has been more than a year since previous release.
> It would be nice to have Tor support, but the existing Tor support code predates #1322 and it will require some effort to adapt to the changes, so it is OK with me not to schedule for 0.6 (but hopefully in a closely-succeeding release).
Oh, I forgot about Tor. I have fixed up my tree (by actually, y'know,
testing it!) and it makes sense to merge on top of the changes I'm doing
for network cmdline which was really triggered by the unix socket
support and Tor.
> Now specifically:
>> 1. The proposed gossip spec enhancements.
>> I've implemented it, just got to test it. It's important for other
>> peers as it greatly reduces their bandwidth requirements, and I'd
>> prefer not to have them avoid our peers because we spam them.
> Seems good, have not read the new specs in detail however.
>> 2. Adding an SHA256 tag to the gossip store.
>> The gossip store is append-only, and not synced: a checksum allows us
>> to ensure it has been saved correctly. This change will require
>> the store to be re-synced, so it's best to do this now before the
>> network grows too large.
> SHA256 seems overkill, as cdecker pointed out in a comment in the github issue. I mostly agree with using a simple checksum (CRC?).
We have crc32 and crc64 routines in CCAN we can use. I don't think
we'll even notice the speed difference, so I suggested SHA256 since it's
already in the codebase.
> The version field in `gossip_store` helps, but it would require a conversion pass at startup. Or we could just truncate a version-0 `gossip_store`.
Yes, truncating on any issues is the right thing for the moment. We can
get smarter later: as the store gets larger we might want to recover if
the corruption is right at the end (where it's most likely).
More information about the c-lightning