As of this writing (5 November 2022), Dogecoin Core 1.14.6 is the latest stable release. If you’re running anything older than that, you should update. We’ve fixed bugs, added features, improved security, added documentation, and made things better.
That’s why we release new versions.
The more nodes running the latest version, the better your experience and the better the network is.
When I say this, people sometimes ask “can we have automatic updates for the Core”?
So far the answer is no, not yet. We have to figure out some things first. Here’s why.
Dog Money is Concerned About the Sick Among the Pure
Software is math. When we’re smart about things, we can use the principles of mathematics to think about the software we write, what it does, what it doesn’t do, and why.
Mathematics has the notion of a function. This is a repeatable calculation,
like “given a value x, add one to it and call the result y”, or y = x + 1.
Mathematics also has the notion of a pure function. This is a function where you always get the same output for any given input and nothing else in the system changes as a result of calling the function.
Cryptocurrency uses this idea everywhere.
Want to validate a transaction? The inputs are “the entire blockchain history up to this point”, “the sender’s public key”, “the transaction details”, and “the result of a calculation the sender had to make with their private key”.
You can perform this calculation yourself. In fact, you must perform this calculation yourself, because Trust Me, Bro isn’t sufficient proof that a transaction is valid.
What does this have to do with software updates?
HEAD Like a Whole
When you download a piece of software from the Internet, how do you know what it is and what it does?
Free and open source software like Dogecoin Core makes the source code available so you can inspect it, change it, build it yourself, redistribute it.
I’m not sure most people who run nodes build the code themselves. Nor should they have to.
Currently we use a mechanism called Gitian to automate and observe the process of building the binaries most people use. Gitian has several important properties that all summarize to this: it’s a pure function.
In other words, the source code of a release (let’s say 1.14.6) is an input. All of the external dependencies like specific versions of Zlib and OpenSSL and Qt are inputs. Versions of compilers are inputs. They go into the function that is “compile this source code with these configuration options” and, if all goes well, we get an output.
If I run a build for what we want to release as Dogecoin Core 1.14.7, I should get the same output as Patrick, or Michi, or Ed, or bluez, or Alam, or anyone.
We can prove that by using another pure function such as a SHA-256 checksum on the output files to compare that they are the same, bit-for-bit.
You can do the same.
You don’t have to trust me or anyone else. You can check our work. In fact, you should check our work.
Pretty Date Machine
In response to people asking “wouldn’t it be easier to get people to upgrade if you made the upgrade process automatic”, I wrote code to show a tooltip recommending an upgrade if your Core is over six months old.
It was easy to write. It’s not much code. It uses the startup tips feature we added a couple of releases ago, and I’m glad it was so easy to write.
If you’re following along closely, you might see there’s at least one flaw in the implementation. (Yes, it was deliberate. No, I’m not above writing code with bugs and problems if it proves a point.)
The first flaw, as Patrick pointed out, is that we don’t have a fixed release schedule, so saying the next release will happen no more than 180 days after the previous release is ambitious. It’s not wrong per se; it’s unknowable.
That’s a process problem and one we can fix. I’ve been arguing for a regular release cadence in F/OSS projects for a while (ignore the framing; the advice is still relevant).
The real problem in this code is this line:
const QDate compiledDate = QDate::fromString(__DATE__, "MMM d yyyy");
The token __DATE__ is a standard predefined
macro
that, as the GCC manual puts it, “expands to a string constant that describes
the date on which the preprocessor is being run.”
You start to see the problem.
If I want to do a release and prove my work through Gitian and compile this
code on October 31, 2022 and Alam comes along and wants to check my work but
it’s already November 1, 2022 where he lives or you want to check both of us
and it’s November 6, 2023, __DATE__ will be different for all of us.
Fortunately, this is a problem we can solve, by moving to a…
Pretty State Machine
… mechanism where we manually hard-code the release date in a header file, instead of relying on the compiler to do it for us. We already do this for version number.
Is this a good idea though?
Just Tell Me What You Want Me To
Maybe.
“Please check for updates” is useful, but not strong. It’d be stronger to say “go to website xyz and click on the Latest Version button”.
Will that website last?
What if you’re in a hotel or at a conference and a malicious actor has hijacked DNS and they can serve you a fake website with a fake download that’ll slowly siphon off all your coins?
What if someone forgets to pay the hosting bill?
What if someone forgets they have the Core installed on a laptop until they pull it out of a box in the closet in 2027 and the update message points them to a defunct site that throws virus after virus on their machine?
One of our community values should be that no one person is trustworthy. Our trust should be in provable things based on multiple sources of validation. Centralizing something as important as the software you’re running and when and how you choose to change that goes against that value.
Is it possible to figure out ways to solve that problem? Trustworthy, automated software updates in an untrustworthy world? Maybe, but dog money’s not looking for that cure.
The Dogeward Spiral
In the meantime, what can you do?
If you run a node or wallet software, please upgrade to 1.14.6.
Please talk to other people and encourage them to do the same.
Take a look at the file signatures in multiple forums (GitHub, Twitter, Dogecoin.com, Discord, your colleagues) and verify that what you’re downloading is what we say it is. If you want to run your own Gitian build or build your own software, feel free to do that as well.
Better to verify than give up control.
