pull down to refresh

Neutrino pulls block headers from the broader network, you don't need to set up your own back end. In most cases this will get a from scratch Lightning node working in a minute or 3.
It also tells lnd to assume channel in the graph are valid by default since its only getting bare minimum information about the chain.
By using a pruned back-end per your OP, it's not doing that, yet it also cannot verify the channels because of insufficient chain history due to pruning, therefore your graph is borked.
Thanks, that helps shed some light on things.
I'm running a pruned back end that serves another node fine. I don't notice any difference in practical usage of a node ( I imagine if I wanted to do accounting or any kind of retroactive query it's not going to be much use though)
My OP was mostly hoping to get an answer about diagnosing issues when doing an initial synctograph. So far, I think I've got it syncing, although it was not getting pongs back sometimes.
For the time being, I think I'm going to stick with pruning as smaller flexible nodes that don't require a shit tonne of resources.
No doubt will look into Neutrino in time (if my next abode has wireless internet)
reply
neutrino is really underrated by node runners
reply
So many people use it and have no idea, which also creates a bit of a problem where there aren't enough high performance nodes serving the blocks.
I run a few boxes out of data centers to provide a CDN of sorts to the network and they're constantly pushing serious bandwidth.
reply
IMHO any serious node runner should activate neutrino in their core nodes. Especially if they run it on clearnet.
Here is also a list of random neutrino nodes but you never know when they can get offline: https://bitnodes.io/nodes/?q=NODE_COMPACT_FILTERS
reply