Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
c-lightning has started sending errors to LND nodes because of their
Tested against @bitconner's node.
Steps to reproduce
We send 01076fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000007b2b400018402 which is:
LND replies with four messages (because of non-zlib):
These responses are incorrect.
There are two problems: first, the range of blocks is wrong, second, the complete flags is wrong.
From the spec:
- MUST respond with one or more `reply_channel_range` whose combined range cover the requested `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one. - For each `reply_channel_range`: - MUST set with `chain_hash` equal to that of `query_channel_range`, - MUST encode a `short_channel_id` for every open channel it knows in blocks `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one. - MUST limit `number_of_blocks` to the maximum number of blocks whose results could fit in `encoded_short_ids`
You do not limit
- if does not maintain up-to-date channel information for `chain_hash`: - MUST set `complete` to 0. - otherwise: - SHOULD set `complete` to 1.
Eclair and c-lightning now need to figure out how to detect and mitigate this for now, and make sure we test protocol compatibility properly in the future!
Thanks for reporting this! We should have the fix for setting the block related fields properly in our next release (0.9). However the fix for our usage of
What does CL use the
I reproduced this in testnet with the latest eclair from
The issue seem to lay out pretty much as @rustyrussell describes it, with the main difference that eclair is actually more forgiving than c-lightning and it ends up being able to sync from LND, i performed a full sync from both the LND node and endurance and the resulting routing tables are almost identical, with the exception of the number channel announcements but this might be because of different heuristics for flappy channels.
In this commit we fix in a bug in `lnd` that could cause other implementations which implement a strict version of the spec to disconnect when trying to sync their channel graph using the gossip query feature. Before this commit, we would embed the request to a `QueryChannelRange` in the response, causing some clients to reject the response as the `FirstBlockHeight` and `NumBlocks` field would be identical for each chunk of the response. In order to remedy this, we now properly set these two fields with each returned chunk. Note that even after this commit, we keep our existing behavior surrounding the `Complete` field as is. Otherwise, current `lnd` clients which rely on this field (rather than the two aforementioned fields) wouldn't be able to properly detect when a set of responses to their query was "complete". Partially fixes lightningnetwork#3728.
Half the fix can be found here: #3785 (still needs proper interop testing)
This doesn't effect any