I published my last Bitcoin tutorial before mandatory signaling on Saturday HERE.
In this video I introduce a service I built for StartOS and Umbrel, to protect Lightning channels during a potential chain split. Forktower is a cross-chain Lightning watchtower which monitors the status quo chain. If any of your channel partners try to cheat you, it notifies you and automatically transmits the penalty transaction to sweep the channel funds for you.
This is a great add Paul! Thanks again. I’m assuming this only works for LND nodes. Luckily I don’t have many channels open on Core Lightning. Let everyone know if there is a way to make this work if using multiple Lightning implementations.
It was originally supposed to support both (and significant work was done for Core Lightning support), however with time running out, I had to focus on LND to get the app shipped in time. I do not recommend trying to use this with Core Lightning, since all of the final polish and bugfixing was only directed toward LND.
Major issue with Forktower – it didn’t detect the chain split. I am working on a fix for this now. Will post a hotfix release as soon as possible.
Forktower 0.6.14 is published. PLEASE UPDATE. The logic was not properly detecting the chain split in previous versions.
Thanks for your attention Paul! Running update now.
Sidenote: LND is having a very hard time syncing to chain on both my nodes after the split
Another sidenote…the fees on the next Bit 4 block are up to $12,165 and climbing
Yeah my LND node is stalled also, reading the BIP-110 chain.
Yes, this is a property of LND that I didn’t fully understand (the Lightning network has an amazingly steep learining curve..) What is happening here is that the gossip data is tightly coupled to on-chain transactions. A public Lightning channel isn’t just “Alice says she has a channel with Bob.” Its identity ultimately refers back to an actual Bitcoin funding transaction. In the traditional gossip system, its short_channel_id essentially encodes something like “block height : transaction index : output index”. So if somebody announces, “There is a Lightning channel at block 912345, transaction 117, output 0”, LND can validate that claim against the node it is connected with. Thus, all of the gossip that our nodes are collecting are referring to transactions which are invalid on the BIP-110 chain.
This basically dashes my hopes for using Forktower as a bridge between the future POW-swap coin and legacy chain. Lightning nodes on separate chains, even with all channels sharing a common ancestry, are fundamentally incompatible in the Lightning protocol.
Don’t see a lot of advice out there as to what we should do next in general. Should we point Knots & LND to the other chain and re-sync, or do we sit tight, leave things as they are and wait? What are y’all doing?
I’ll have a video out soon once I work out the best process. I’m experimenting with this now on my test servers which all are in this state.
I’m defiantly weighing my options but I’m leaning towards Knots (pre RDTS). I will not go back to Core
I have stopped all rented hash pointing at the BIP 110 chain though.
I’ve also stopped mining. This makes sense at this time as pleb mining isn’t going to be enough to save the bip110 chain.
I have a few nodes and have also configured knots to the 20260507 version (Pre RDTS enforcement).
It quickly caught up with the suit chain. Mining doens’t make much sense for now until we see what’s gonna happen with knots in general.
Ideally, I would like to see a new version of knots which removes the obligatory bit 4 (bip110) signalling so that all blocks are again accepted, but would continue to block and reject the spam transactions. We can still grow the amount of knots nodes out there to help reduce spam, but now the approach will be different. We need 51% of the nodes being knots (to my understanding).
Once it’s clear that mining your own template helps, we can go back to mining. Right now, HR is way down on ocean, so it would be a long time to make your sats back.
