Saw the first couple of users confused about why their knots daemon suddenly forked them off the network.
Discussion
Yeah, except for the "feature" that forks off your node if you run a client older than ~2 years.
Wait, what?
It is the -softwareexpiry startup option, which is default on. I think most people do not know about it.
https://github.com/bitcoinknots/bitcoin/blob/28.x-knots/src/validation.cpp#L4458
I did not know that. This is dangerous!
So 23.x? Knots 25.1 isn't 2 years old yet...
Haven't done the actual calculation, but seems to check out.
Anything with COPYRIGHT_YEAR=2023 expired Nov 2024, including knots 25.x. Versions 26.x and 27.x will expire Nov this year. So every other knots release is a hardfork by default (newer versions will accept blocks that older versions would reject), neat!
I just learned about this. I was under the impression that is just stopped accepting blocks, not a fork more of a shutdown.
Kind of ingenius, actually. It forces people to pay attention to their node. It's like a rust panic.
Is it actually forking the chain?
Other nodes will continue following the most PoW valid chain but old Knots will reject that chain and instead accept backdated blocks on a lower PoW chain.
Oh that's weird. Not like a panic at all.
how would I even notice this?
I haven't had a knots node hit this point but you'll notice when you go to create or confirm a transaction and your node is not synced with the blockchain.
You might not even notice right away if someone is actively exploiting your desynced node.
I think a better design would be to have the node crash when time runs out. This brings the problem to the node runners' attention without opening an exploit.
The logic of that function seems pretty weird. Why use nTime instead of system time? Why reject blocks instead of shutting down (or simply nagging the user)? The way it's designed seems possible to abuse, whereas other easy choices would have much lower risk of problems.
Yeah, idk