Skip to content

Releases: btclib-org/portanode

Release list

v2026.9.7

Choose a tag to compare

@fametrano fametrano released this 07 Sep 20:25
v2026.9.7
c767722

This is the first release published on the forge, and every entry in
this section states what changed relative to the folder as assembled on
2026.01.27, which was never tagged.

A rollback now refuses to run while the node it replaces is up. Stop
Bitcoin Core or Electrum before running rollback-bitcoin or
rollback-electrum on either platform: a rollback replaces the same files
an update does, and the update scripts refuse on the same condition.

A rollback that could not restore now reports it and exits non-zero,
where Rollback complete and an exit of 0 followed either outcome. On
macOS the installed app is renamed aside rather than deleted, so a restore
that fails leaves the version that was installed in place. Each rollback
also says on the way out that it has consumed the backup: there is nothing
to roll back to a second time, and update-bitcoin or update-electrum
is what installs the current release again. On macOS the command-line
tools beside Bitcoin-Qt.app are not rolled back with it, the backup
holding the app alone.

An update now refuses to install a binary it could not verify. Both
platforms' update scripts abort unless the download carries a valid PGP
signature from a key already in your keyring; before, a missing gpg or
a missing key warned and installed anyway. Import the publisher's key
before the next update — README.md's Updating Binaries has where each
comes from — or set PORTANODE_ALLOW_UNVERIFIED=1, which installs
unauthenticated binaries and is there for the case where that is a
considered decision rather than an accident.

keys/electrum.fingerprints pins the Electrum release key, so an
Electrum download signed by any other key is refused even with the key
imported. keys/bitcoin-core.fingerprints pins nothing, Core's
SHA256SUMS being signed by many independent builders; add the
fingerprints of the builders you choose to trust if you want that
half pinned too.

The regtest clean launchers now stop and ask. Every one of them waits
for a confirmation before deleting a datadir, where some deleted first
and one asked nothing at all. On macOS they also refuse to wipe a datadir
a running node is using, rm -rf under a live node being how that node's
data gets corrupted rather than reset.

The Windows regtest clean launchers refuse to wipe a datadir a running
node is using
, as the macOS ones do. Stop the node before a clean start;
where the check itself cannot run they refuse as well and delete nothing.
mainnet-8333-qt.bat likewise refuses to start a second mainnet node.

Updates now stage on the local disk and copy only the finished
binaries onto the removable volume, so a %TEMP% or an APFS mktemp
directory needs the room the download used to take on the folder itself.
The macOS copy re-reads what it wrote and retries until it matches, which
is what the exFAT corruption this works around asked for.

set-permissions now exits non-zero where it did not restrict the
data directories
, where an exit of 0 followed every outcome. On exFAT
or FAT32 — a filesystem this folder may be built on — the run exits 2,
and the Utilities Launcher prints Command failed (exit 2). after the
warning that volume already drew: nothing about the folder has changed
there, and encryption or physical control of the device is still what
protects it. Exit 1 is the run falling short of what the volume can
hold — an account that does not resolve, a path chmod was refused, an
entry granting somebody else access — and acting on what the message
names is what clears it. A script or a scheduled job chaining one of
these scripts now sees a failure where it saw success.

A Windows folder on ReFS is reported as what it is.
set-permissions.bat reads the ACL back off each data directory rather
than trusting the filesystem's name, so any volume that stores an ACL is
reported on what it carries; ReFS drew the warning that the directory is
readable by anyone with access to the volume while in fact carrying the
grant. Where that warning was acted on — by moving the folder off
ReFS, or by adding protection around it — the reason for doing so was
not there, and this release is what says so.