Here are the last few entries:
2025-09-02T17:44:10+01:00 2025-09-02T16:44:10Z CreateNewBlock(): total size: 1104004 block weight: 2916841 txs: 2496 fees: 3717164 sigops 11017
2025-09-02T17:44:14+01:00 2025-09-02T16:44:14Z Saw new header hash=00000000000000000001d03eb01f5fcb46147315577611b37f96785673fe00de height=912901
2025-09-02T17:44:20+01:00 2025-09-02T16:44:20Z UpdateTip: new best=00000000000000000001d03eb01f5fcb46147315577611b37f96785673fe00de height=912901 version=0x33c72000 log2_work=95.802853 tx=1236121343 date=â2025-09-02T16:43:49Zâ progress=1.000000 cache=2.0MiB(14939txo) warning=âMiner violated version bit protocolâ
2025-09-02T17:44:20+01:00 OK2025-09-02T16:44:20Z CreateNewBlock(): total size: 182902 block weight: 443737 txs: 459 fees: 269755 sigops 1754
2025-09-02T17:45:02+01:00 2025-09-02T16:45:02Z CreateNewBlock(): total size: 320364 block weight: 871374 txs: 695 fees: 723084 sigops 4750
2025-09-02T17:45:40+01:00 2025-09-02T16:45:40Z Saw new header hash=00000000000000000000f584ccc963883814f5c46998297eb447d5160e1cea64 height=912902
2025-09-02T17:45:45+01:00 2025-09-02T16:45:45Z UpdateTip: new best=00000000000000000000f584ccc963883814f5c46998297eb447d5160e1cea64 height=912902 version=0x25912000 log2_work=95.802865 tx=1236123804 date=â2025-09-02T16:45:27Zâ progress=1.000000 cache=3.7MiB(26566txo) warning=âMiner violated version bit protocolâ
2025-09-02T17:45:45+01:00 2025-09-02T16:45:45Z CreateNewBlock(): total size: 98463 block weight: 241023 txs: 268 fees: 156053 sigops 1042
2025-09-02T17:46:26+01:00 OK2025-09-02T16:46:26Z CreateNewBlock(): total size: 182177 block weight: 442439 txs: 497 fees: 454094 sigops 1709
2025-09-02T17:47:08+01:00 2025-09-02T16:47:08Z CreateNewBlock(): total size: 277507 block weight: 672427 txs: 720 fees: 718784 sigops 2571
2025-09-02T17:47:49+01:00 2025-09-02T16:47:49Z CreateNewBlock(): total size: 438837 block weight: 1040037 txs: 942 fees: 1021268 sigops 3486
Nothing unusual there. I usually see that error you mentioned when validating a block takes longer than expected (it resolves itself once validation is completed). That typically happens on systems with 8GB RAM or less, though, which is not applicable in your case. If your RAM usage is fairly low like it was in your earlier post, that is a bit of a head scratcher.
In addition, Bitcoin Knots is stuck in shutting down mode again, after I took a look at the config. I did not make any changes.
Do the logs indicate why it is shutting down?
Not seeing anything in the logs that suggests why.
At 31:15 in the video, you generate a new wallet address with sparrow and label it as âOcean Walletâ. But all the transacting you are doing is in CL. Why not use the âCLN Walletâ address at the top of the text file?
Because you need to sign a message when setting up Lightning payouts, to prove you own the address you are using as your account on Ocean (otherwise anybody could just add their own lightning offer to your account and steal your mining payouts). CLN doesnât have a way to sign messages with the base layer wallet keys.
Interestingly, LND actually does have a command for signing messages (though you have to do it from the terminal since an interface for it is not exposed in RTL). Unfortunately LND doesnât have support for offers yet though.
Ok, but how does CL know about an address that wasnât generated on CL in the first place? Said another way, how can I deposit funds using CL to a sparrow wallet address. When I go to my CL node to deposit on-chain BTC, I always get a fresh address, not the one sparrow would have generated for me.
Maybe some context will help to better understand my situation:
I just got my Start9 a week ago.
I have Knots, Mempool, CL, LND, RTL, Electrs, and Datum installed and configured.
I havenât set up sparrow yet because I already have a hardware wallet that can sign transactions. Iâve just been depositing BTC from my Trezor directly to my CL and LND nodes and generating liquidity that way.
Iâm currently trying to get my NerdQaxe set up to mine on Ocean via Datum.
CLN is separate from the base layer address used to create the Ocean account in this setup. It doesnât need to know anything about the address. The address identifies you in Ocean, and you prove you own it by signing a message. The message you sign is generated by Ocean when you enter a Lightning offer to link with your Ocean account. The Lightning offer is generated by CLN. So it is really just Ocean itself which links the two together, once youâve proven to them you are the real owner (with the signature)
You can use the cold wallet you already have for this (no need for a hot wallet). Install Sparrow on you computer or laptop, and connected it to electrs on your server. Then connect your Trezor signer to Sparrow (Sparrow replaces Trezor Suite in this setup). You can use Sparrow to generate an address to use as your Ocean account if you havenât already done that with Trezor Suite. Then you can use the message signing interface in Sparrow when you get to that step. The only slight difference from what I showed in the video is the actual signing with the private key will happen on the Trezor signer (just like when signing a transaction)
Hehe, thatâs pretty much the first thing I tried when setting this whole thing up less the sparrow wallet part. I just figured out a few hours ago how to connect my Trezor to Sparrow on my main workstation. The electrs connection was the only missing part of that stage of the setup. Iâll do that now.
That said, Iâm still not sure how to connect that wallet to CL. When I initially tried setting up my Datum connection, the Bolt12 message I signed using the Trezor suite was accepted by Ocean. But when the next block was found, ocean couldnât find a lightning channel:
I never could figure out how to add the Ocean wallet address to CL?
UPDATE: I got sparrow local connected to my host electrs. Or at least the passing test connection in sparrow indicates as much. Iâm not seeing any differences on Start9 or either of the CL or LND nodes. Not sure what to do next.
That error isnât related to the wallet. As long as Ocean accepted the signed message, you should be good there, I think.
The next thing to check is if you have inbound liquidity. Make sure most of the sats on your CLN <> LND node are on the LND side. And then on your LND node make sure there is a second channel with a well-connected node, and make sure there are enough sats on this other nodeâs side.
Then test everything by creating an invoice in CLN and paying it with some other source (Aqua Wallet, Strike, etc.). This will confirm that payments can be routed through your LND node to your CLN node.