Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add --noprivate flag to describegraph rpc to filter out private channels #1389
Add --noprivate flag to describegraph rpc to filter out private channels per #1037
Initially I named the flag
Note: this additional parameter needs to be added to the describegraph cache issue #1232
Testing done on simnet:
On Charlie's side, run describegraph and describegraph --noprivate and compare outputs. Only difference is that when --noprivate flag is on, the private channel was not included in the output.
I've redone the test above to verify correct operation of describegraph with and without the private flag.
I try to make sure to do a proto gen upon each commit. I'm using the versions for the generator specified for lnd. It does though introduce a small number of changes in other places in code in rpc.pb.go and rpc.pb.gw.go. I patch those back, using the diff of running the proto gen on the master branch. Most of the changes seem trivial, i.e. one liner function instead of 3:
I double checked the versions on golang/protobuf and grpc-ecosystem/grpc-gateway.
I'm not sure what is causing this. I don't think this has consequences on this PR, but it would be nice to know how to fix it such that when I regen proto on master it will not generate any changes at all, as it should.
@halseth, I rebased again, as master moved forward and a conflict was detected in rpc.bp.go. I rerun gen_proto, rebuild, go test, and run the specific tests above.
@halseth I need some help here :-)
The code I added assumes that non-private channels, or more accurately their edgeInfo, always have a non-nill authProof. This works when I tested with lncli. However this check/assumption fails for non-private channels in the integration tests. I am not sure why though.
Looking at other code in rpcserver.go that checks for private channels, e.g. like ListChannels, the code checks whether the channel is private by comparing the channel flags against lnwire.FFAnnounceChannel
What I'm thinking of doing, is instead of checking if authProof is empty or not, add a function that gets all private channels, and somehow check whether the edgeInfo being iterated upon is private or not by checking whether it is/reflects one of those channels.
Is it the right direction to go?
Non-private channel should have an authproof after the funding transaction has received 6 confirmations. However there can be cases where this doesn't get created, if one of the channel parties goes offline for instance before those 6 confirmations. In such cases the channel won't be active though, so it shouldn't be very interesting.
What integration test is failing because of this?
@halseth The following tests fail:
'open_channel_reorg_test' fails at:
'channel_force_closure' fails at:
'private_channels' fails at:
'test_multi-hop_htlc_local_chain_claim' fails too. I stopped there...
Regarding 'using FFAnnounceChannel to filter out private channels is a possibility, but note that we only have these flags for our own channels.', yes, but per my understanding we are not aware of private channels (edgeInfo) that are not ours, right? Otherwise, if we got those through gossip they are public.
@Bluetegu I don't think your changes should affect the first two tests you mentioned, so that is probably a different bug... I think I have PRs up that fixes both these two flakes.
For the test
You are absolutely right,
Awesome work on this one! Thanks for sticking it out with my pickiness, now it has gotten to a state where I am happy with the overall changes
The comments are mostly style suggestions and nits, otherwise this looks good. Also thank you for splitting up into separate commits, makes reviewing much easier!
I'm not a native English speaker so please bear with me on this.
The current comment is "Close channel"
BTW, do you want me to switch to closeChannelAndAssert?
BTW, I'm not sure how the 'resolve conversation' here in the discussion of the pull request is supposed to work: do I need to press the 'resolve conversation' once I fix the issue, or is the reviewer (you) supposed to do that once the issue is indeed fixed, or we should simply ignore this github feature altogether.
I'm not sure how the 'resolve conversation' here in the discussion of the pull request is supposed to work.
It is a new feature, so I'm not totally sure either