That was quick. Did you do a Faster first sync?
I did. The 2nd sync is almost finished too.
1 Like
Took about 5 hours from start to finish. Both nodes synced and now Forktower is watching the channels.
Looks the same as what I saw.
Ah. So you are 0.4.0 then. 
Thanks for the heads up.
Major issue discovered and fix is in progress â On StartOS 0.4.0, LND is not able to connect to Forktowerâs watchtower interface over the clearnet internal IP (because it is dynamic and changes after each start, including after updates). The connection needs to be over Tor. Iâm adding this now, but heads up that you will definitely want to update to Forktower 0.6.10 (or later) once I publish it. It may also require adding a new address to your LND Watchtower config (Iâll see if that is needed once I get deeper into it).
Without the update, Forktower will watch the other chain and notify you if you are being cheated, but it will not be able to transmit the penalty transaction for you (and most people would not know how to do that manually).
1 Like
Do you see a message under What is in Place something like this?
Still catching up with the other chain
Forktower cannot see the whole picture yet. This usually finishes on its own.
About 98% of the way there.
or
Some channels are not covered by a watchtower
A breach against those channels would not be answered.
no session yet, and this is not your node's doing: the tower's own Bitcoin node is still catching up (height 954508), and the tower does not accept sessions or watch for breaches until it has finished. Your node is already asking, on a retry, and a session will be agreed on its own once the tower can answer â there is nothing for you to do
Actually, I did find a similar problem on 0.3.5.1 that I mentioned for 0.4.0. It is a slightly different shape, but the solution will be similar. Iâll add that as well to the hotfix.
1 Like
Close to the error I have:
When I look at:
I do see my channels listed in this table
Iâll check in tomorrow.
Hotfix is published. You should see a message under Things Worth Knowing mentioning that youâll need to update your LND config to use the Tor address (instead of the local address that you added before). But if not, you will still need to do this step (get forktowerâs onion address, and go replace the value in LND for the watchtower client with that new value. It will take a few minutes for LND to connect to the watchtower. After that, there should be no remaining errors or warnings in the UI (besides the one that indicates there is no chain split yet).
1 Like
That is a feature for a prolonged chain split where both sides of the chain have some weight behind them (a scenario the game theory makes highly unlikely). In the case that you open a new channel on your chain, and you want to make sure that channel is preserved if your side of the chain ultimately loses, then this triggers a replay on the other chain so that your channel exists on both chains.
Note that in a soft fork, both sides of a chain split share the same network of mempools, so this replay will likely happen already by default. Iâm more thinking ahead to the possible scenario where a lot of our side decide to hard-fork to a new coin if BIP-110 fails. In that scenario, Forktower could operate in a long-term cross-chain scenario, where you might want to keep one foot in the door on the other chain in case you decide to return in the future.
2 Likes
Ive noticed this 2 times now about 1 hr agoâŚbut since then the message hasnât repeated. StartOS 0.3.5.x
All well
Watching. Your channels look fine.
Your node and the rest of the network are on the same chain.
The above is fine ^^^
Things worth knowing
Forktower raised an alert: your node is registered with this watchtower and the tower is running, but not one channel state has ever reached it â no backup, since the day you registered. Nothing on your node will tell you this: it still lists the tower as usable and retries in silence. The registration itself is fine. What is wrong is the address inside it: your node cannot open a connection to it. That is what happens when the node sends its connections through Tor, which will not carry one to a local network address. The tower now has a Tor address, which your node can reach. Re-register it with the new address â the old one will not start working on its own: lncli wtclient remove (my onion address here) lncli wtclient add (my onion address here). Nothing is lost by doing this: no backups were ever made under the old registration, and your channels are protected from the moment the first session is agreed, which takes a couple of minutes.
What has happened
8/7/2026, 12:31:20 PM â Forktower raised an alert: channel 57a3413eâŚ:1 is not protected by this tower: both ends support anchor sessions but the node has not negotiated one with this tower, so this channel is not being backed up.
This repeats for all 6 channels as shown (in second image) above
If is a nothing burger after another day of runningâŚso be it..in the meantime is it a possibility that I have 2 Watchtowers now and I have a conflict? Watchertowerâs are Node2 LND + Forktower
Yes, this is a possible scenario (a stale watchtower endpoint). I have hotfix 0.6.12 in the works now which should detect this and provide you with instructions. Iâll let you know once I push it so you can see if it detects the cause of that error it is reporting or not.
Most likely in your case (since you saw that it went away both times) it is probably just a network glitch or low timeout that can be ignored. But with 0.6.12 youâll be a little more confident. Just give it some time after updating (when Forktower restarts it generates a bunch of alerts that go away after some time).
Hotfix 0.6.12 is published.
1 Like