pull down to refresh

Have a few questions pertaining to setting up a new node. Basically, I always seems to be unsure about syncing to graph, after syncing to chain. Consider setting up a new node from scratch, or migrating perhaps, and you want to do an initial setup.
  1. How long does it take?
  2. What factors determine how long it takes?
  3. Is the graph a universal graph that is identical from each nodes perspective?
So far, I'm monitoring progress but tailing logs, looking for clues:
tail -n 100 /data/lnd/logs/bitcoin/mainnet/lnd.log | grep GRPH
I can find some relevant clues like:
2025-01-30 15:24:54.843 [INF] GRPH: Processed channels=56 updates=59 nodes=15 in last 59.823699481s
and then checking with: lncli getinfo | grep -E 'synced|peers which outputs
    "num_peers":  3,
    "synced_to_chain":  true,
    "synced_to_graph":  false,
At the moment, I've been experimenting with pruned blockchains and this outputs a lot of errors (I believe) relating to not being able to verify UTXOs as I have `ignore-historical-gossip-filters set to true.
Any further suggestions on how to better make sure things are happening under the hood when setting up a new node, what to look for in the logs or how to know the verification progress?
reply
Interesting. had not really considered looking at Neutrino yet.
What do you do for the bitcoin node back end if you were travelling and didn't have a synced node, so you need to connect to public back end? It's not particularly fitting to my use case, but I appreciate the response.
reply
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.
reply
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
Did you ever used Breez, Blixt, Zeus on your mobile? All are LND nodes based on neutrino. Here some guides:
reply
I'm retarded when it comes to being on the cutting edge of technology. I'm building up my knowledge of Debian, Ubuntu, Bitcoin Core and LND only. PostmarketOS, LineageOS on mobile.
Maybe in the future I'll get a Pixel, look into Graphene and get the node in my hand.
I did try Blixt, that worked well on my iphone, but I dropped the iphone in the sea on holiday this summer.
Appreciate the ideas.
reply