New litd installation streaming endless errors (L402 token invoice & did not get response before timeout)

[GTCLive]

Hi, after 9+ years of running a bitcoind node I finally decided to give LND a shot! However, without much luck :( I need help.

Debian 12
Bitcoin Core 27.1
Lightning Terminal v0.13.5-alpha

The installation is bone stock. Debian 12, Bitcoind & RPC all works perfectly fine. Litd not so much... see logs. I'm not even sure if the system was compromised and/or hacked up during the installation of those google/go packages. it's multi-tasking invoices payments and other stuff. Not sure what to make of this.

Anyone seen this before and perhaps be able to decipher this log trace?

Litd_log.txt

bitcoin.conf

prune=550
rpcuser=rpcuser
rpcpassword=123456789
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

lit.conf

uipassword=123456789
lnd-mode=integrated
lnd.alias=mecanix_dev
lnd.color=#00ff00
lnd.wallet-unlock-password-file=/home/cnc/.lit/wp
lnd.wallet-unlock-allow-create=true
lnd.bitcoin.mainnet=1
lnd.bitcoin.node=bitcoind
lnd.bitcoind.rpchost=127.0.0.1
lnd.bitcoind.rpcuser=rpcuser
lnd.bitcoind.rpcpass=123456789
lnd.bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
lnd.bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333

[sputn1ck]

Hi!

Are you referring to the 2024-10-26 20:24:59.965 [ERR] NTFNS: Error fetching L402: insufficient_balance error?
If yes, this error is currently expected as long as you don't have any outbound liquidity.

Do you notice anything not working as you would expect?

[GTCLive]

@sputn1ck Thanks for letting us know what to expect. Quite frightening given the financial context; not everyday that a fin soft installation auto-process invoices and tries to pay them on its own lol Honestly thought the system had exploits and/or got compromised in the install process, and therefore grabbed the log trace above, pulled the cat6 out and closed the whole system down.

That said, I weren't able to notice anything (else) not working. Apart from the endless stream of [ERR] on those timed out queries ofc. Are those timeouts also to be expected?

Thx

[ellemouton]

@GTCLive - it looks like you are not connected to reliable peers potentially? How many peers are you connected to & is your lnd node synced to the graph? (lncli getinfo). Also looks like you dont have any outbound capacity.

[GTCLive]

Guys. I was perhaps mislead to believe that LND was compatible with a pruned bitcoind node. My understanding is; what is not found locally get fetched from my connected bitcoind seeds/peers (at a higher bandwidth cost & lower speed ofc). If that assumption is correct, then LND doesn't seem to work at all - it's looping into a persistent timeout state rather. Bug?

I've put a 2Tb hdd on order and should receive this today. I'll copy over the blockchain and indexes from my full node onto that new hdd and hook it up to this LND test-laptop. If everything works out then my question will be answered, and it'll be fair to assume the pruned lnd feature does not work.

I'll update on progress.

[dstadulis]

LND was compatible with a pruned bitcoind node

LND does support operating on a pruned bitcoind node, and even without local access to a bitcoin node by connecting to Neutrino nodes. See educational docs here:

https://docs.lightning.engineering/community-resources/glossary#neutrino
https://docs.lightning.engineering/lightning-network-tools/lnd/run-lnd?q=pruned

Pruning nodes can result in brittle operational performance due to the need to obtain transaction / block data. An node operator should weigh the balance of costs between the capex of disk space and the opex of debugging / maintenance.

[dstadulis]

Feedback on the logging messaging is appreciated. An improvement to avoid this behavior, in the future, is in progress: lightninglabs/loop#841

[GTCLive]

@dstadulis That would be correct. Seems to be functioning up to spec and quite well with a full local blocks/indexes stored locally. Epic failure when/if pruned. Lesson learnt. Thanks.

Awesome amendment on #841 👍💯

Closing this.