pull down to refresh

Nice find, but I think it's not as bad as it looks.
It doesn't "stop working" if it's already running, it will only not start again if you don't do what the message tells you.
I think the message makes sense. Let the user know that they are running an outdated version and if they don't care, they can simply pass -softwareexpiry=0 to continue running that version.
No, it does stop working for all intents and purposes. At the timeout will start rejecting blocks, effectively forking the node off the chain. If timed correctly, the node could be fed a chain with less work. This is arguably worse than just shutting down, since other services relying on the node will not notice immediately.
reply
2 sats \ 0 replies \ @ek 14h
You're right, I missed that this code runs inside CheckBlockHeader. Thank you!
reply
This answer of yours is in line with what I was reading elsewhere. This is worrying. It is true that in two years, everything could change, maybe other programmers will start working on Knots and things could change. I was installing a well-known Knots, when they cut my fibre optic cables and now I am without a network for the whole week.
reply
Ok, on the one hand it is correct to incentivize the user to abandon software that is no longer supported, but on the other hand, I see it as a sort of censorship.
Let's try to look at it from this point of view: many users are thinking of switching to Knots for everything that has happened around the issue OP_RETURN, let's say that all (or most of the community) switches to Knots, Let's say that in a year Luke decides to make an update that the community doesn't like, the user wouldn't even be free to continue to keep an old version active without having an annoying warning.
What do you think?
reply
50 sats \ 6 replies \ @optimism 6h
it is correct to incentivize the user to abandon software that is no longer supported
I think incentivize is wrong because the incentive should already be there in the form of bug fixes and new features. Rather, notify would be better: could just leave a warning / popup instead of literally messing around with consensus code.
It's not censorship though imho, it's immatellyouwhattodoship.
Here's your magic letmelivemylife.patch fwiw:
diff --git a/src/clientversion.cpp b/src/clientversion.cpp
index 6bf7ef6406..488d6abcb6 100644
--- a/src/clientversion.cpp
+++ b/src/clientversion.cpp
@@ -108,8 +108,5 @@ int64_t g_software_expiry{DEFAULT_SOFTWARE_EXPIRY};
 
 bool IsThisSoftwareExpired(int64_t nTime)
 {
-    if (g_software_expiry <= 0) {
-        return false;
-    }
-    return (nTime > g_software_expiry);
+    return false;
 }
reply
Make a PR ^_^
reply
Now that would be a waste of precious time!
reply
reply
Besides this being an ad-hoc patch and not something you'd want to publish, all it's going to do is waste everyone's time because drama, and then it gets closed. If Luke wants to tell you what to do, my patch is not going to succeed in telling Luke to not tell people what to do, while also being kinda hypocritical - after all who am I to tell Luke what policy his software should have.
Let me ask you this though: if you had a node software that was written for full operator autonomy, with no nasty shit like this, full transparency in the development process and an open repo where people can freely argue... would you run that software? would you encourage others to run it? would you contribute to it?
0 sats \ 1 reply \ @ek 14h
What do you think?
You lost me at "a warning is a sort of censorship." My opinion didn't change.
If you don't like it and really cared, it's literally a few lines of code you could patch out.
Don't be an entitled FOSS user.
reply
A few lines of code, but getting your hands on it without adequate testing, leads to frightening risks. One of the biggest criticisms made of this decision to remove the OP_RETURN limit is the lack of testing on this implementation. Here we would be in the same solution.
reply