The software that runs bitcoin entered its final stretch on Monday. The first release candidate of Bitcoin Core 32.0 was published on September 14, and if the tests don't turn up any nasty surprises, the final version will land on October 10. For most of the world, it's a line in the logbook of a few volunteer developers. For those who run the network at home, it's the most interesting update in months: three times less waiting to join the machine, two holes plugged, and a format change that's going to wake up computer scientists in the middle of the night.

A quick reminder to set the scene, because a version number means nothing to anyone. Bitcoin doesn't have a central server. The transaction ledger exists in thousands of copies, with people who install a program on their computer, leave it running all the time, and each check for themselves that everything moving through it is above board. That program is Bitcoin Core for the vast majority of them. It's not mandatory, nobody forces you to install it, but it's the one keeping the books and deciding what is a valid transaction and what isn't.

When software like this changes version, it's not an application getting a makeover. It's one more part in the machine keeping the network standing. And this time, good news, the validation rules aren't moving an inch. The work happened elsewhere: in speed, in fees, and in two vulnerabilities.

Three times less waiting to join the network

When you install the software on a new machine, it doesn't start by saying hello. It gets to work rereading the entire history of transactions since 2009, block by block, before it can be useful for anything. That's what we call synchronizing, and it's slow. Days, on a normal drive, during which the machine wheezes and you get nothing in return.

That's where version 32 speeds things up. Until now, the program fetched the information it needed one piece at a time, queueing up every time. It now asks for several pieces at once. The developers' tests show synchronization up to three times faster.

Three times, it sounds like nothing when you put it that way. In reality, it's the kind of detail that decides whether someone gives up after two days or makes it to the end. Checking for yourself that your bitcoins really belong to you, without trusting an exchange platform, has never been fun. Every hour saved there is one less reason to let someone else do it in your place.

A memory hole found with an AI model

The fun part of this version is that one of the two vulnerabilities was uncovered with the help of an AI model. A project contributor, Matthew Zipkin, was combing through the software's new web server, the one that lets it talk to the outside world. He got help from Kimi K3, a model that isn't related to the ones I use every day, and the duo found a way to make the machine's memory swell until it choked.

The painful detail: the fix initially solved half the problem, and it was a reviewer, looking closely at the patch, who noticed that connections without the slightest identifier could still make the memory swell. After revision, sixteen anonymous connections over ninety seconds make the program grow by three megabytes. Before, the same sixteen connections and the same ninety seconds made it swallow three gigabytes two tenths. A thousand times less, for the same nastiness.

Enough to turn a machine that does its job into a machine that no longer responds, in a minute and a half, without creating a single account

The fix has been merged since September 5. Two things to take away from it, and the second matters more than the first. An AI model was used to review old code and find what humans had missed, that's becoming a habit and it's not bad news. And the intermediate fix that only fixed half the problem is a reminder that closing a door means checking the handle afterward, not just slamming it shut.

A contributor, a model, and a hole nobody had seen for months

The other vulnerability was hiding in a conf file

The second one is sneakier, and it had been lingering since version 24.0 on every machine that doesn't run Windows. It concerns an option node operators love because it comes in handy: it lets them ask the machine to execute a command of theirs as soon as a transaction touches their wallet. Warned in time, you can trigger an alert, wake up a script, do whatever you want.

# dans bitcoin.conf
walletnotify=/usr/local/bin/prevenir.sh %s

The problem is that the name of the wallet that triggers the command was copied over without being cleaned up. A wallet given a carefully chosen formula could therefore make something other than the intended script execute, on the machine of the person hosting it. To do that, you already had to be a recognized user of the node, which limits the damage, but the door was open and stayed that way for eight major versions. It is closed.

Two holes closed at once in software that runs an entire network, that was already seen last month over at BNB Chain, and every time the scenario is the same: it is never the spectacular vulnerability that costs a lot, it is the detail nobody had looked at.

The trap comes later, and it's for other software

Here is the part the developers are going to curse and that I find, myself, rather healthy. Four commands in the software change their default format on October 10. They are used to exchange a half-signed transaction between a wallet and the device holding the key, that sort of form the two of them pass back and forth so the signature lands in the right place.

Applications can still request the old format, so nothing breaks overnight for the user who has an up-to-date app. But exchanges, custodial services and wallet manufacturers that talk directly to Bitcoin Core had better test the release candidate now, rather than discover the change on the morning of October 11 with unhappy customers. The project is telling them the same thing, in diplomatic terms: try it beforehand.

The form passes from hand to hand, except that if the version changes along the way, the signature ends up in the wrong place

That is exactly what we ask an update to do. Warn early enough for the work to get done during the week, and not on a Sunday night.

So, what does this change for you?

If you have bitcoins on an exchange and never install anything, today, nothing. Absolutely nothing. You don't have a copy of the ledger to maintain, and other people's work only affects you if their software breaks, which is precisely why they are being asked to test before October.

If you run the software at home, on the other hand, you have a date. October 10, or a few days later if a test goes wrong, is the time to move to 32.0. Not before: a release candidate is made to be tested, not to keep your savings in. And for those who were hesitating to get started because synchronization took forever, this will be a chance to try again, on the old box gathering dust in a cupboard.

One piece of honesty to finish: fee rates have also been reworked. The program can now estimate the price of a transaction by looking at those waiting their turn, and not just the blocks that have already been filled. On a lightly loaded network, it will suggest a lower price, which is a real improvement for anyone who sends three transactions a month and cried over every bill.

There is one question nobody will ask before it starts to hurt: how many of these old pieces of software that run the network have never received a single update since “walletnotify”? A forgotten node on an old disk never complains, never restarts, and keeps the door ajar for years.