Skip to content

v2.0.4-Triune

Choose a tag to compare

View all tags
@github-actions github-actions released this 03 Jun 16:48
· 73 commits to main since this release
v2.0.4-Triune
5b67855

What's new in v2.0.4-Triune

Tags the Restoration-prep work for the Codex window. Two consensus changes ride this release.

1. Emergency-difficulty escape valve (b6d626f)

  • Activates at block 989,898 (~3.5 days at 60s pacing from cut).
  • Relaxes the strict nBits == GetNextWorkRequired check for a single block when there is a >1h gap since the prior block AND the new block carries nBits == ProofOfWorkLimit (min-diff).
  • Companion to LWMA-3 — gives the chain a recovery path if Quark hashrate departs and leaves the difficulty target stuck high.
  • Hard-skipped during the Conclave signed-mining window [999991..1050666] so Descent / Codex blocks stay pool-only even under stall.

2. Triune Conclave (a9859c5)

  • Adds two additional signing pubkeys (Conclave Key #2 and Conclave Key #3) to vConclaveKeys alongside the original Conclave Key #1.
  • Any one valid signature passes CheckConclaveSignature — loss of two of three signing boxes still permits the third to keep the chain advancing through the Codex window.
  • Activation: block 999,991 (Codex window opens). Old binaries reject blocks signed by Conclave Key #2 or Key #3.

Operator action required

Deadline Why
Block 989,898 (~3.5 days) Otherwise you reject any ED-relaxed block as bad-diffbits.
Block 999,991 (~10.5 days) Otherwise you reject any block signed by Conclave Key #2 or Key #3 as bad-conclave-sig once the Conclave window opens.

If you only run the legacy single-key binary today, you still need to upgrade — its chainparams must also know about the new signing keys to keep validating its peers' blocks.

Verifying downloads

sha256sum -c SHA256SUMS-linux.txt
sha256sum -c SHA256SUMS-windows.txt

Codename

Triune — three Conclave signers, the load-bearing change for redundancy during the 35-day Codex window.

Built via CI from commit 5b67855 (configure.ac bump on main). Linux x86_64 daemon + cli (glibc 2.35+, depends/ static). Windows x86_64 Qt5 wallet cross-compiled via mingw-w64 + depends/.

Hardening recommendation: -upnp=0 for public-facing nodes

If you run a publicly-reachable OFFd, set -upnp=0 and configure -externalip=<your.real.ip> explicitly:

offerings.conf:
  upnp=0
  externalip=<your.real.ip>

Why. UPnP-IGD address discovery in miniupnpc trusts whatever device responds first to the SSDP multicast at 239.255.255.250:1900. A hostile device anywhere on your LAN — any guest-wifi user, any compromised IoT device, any unpatched roommate machine — can race the real router with a forged response, then return an arbitrary <NewExternalIPAddress> over SOAP. OFFd feeds that into AddLocal(addr, LOCAL_UPNP) and gossips the attacker-chosen IP to peers via addr and version messages. Attack primitive is eclipse-attack staging — the same protocol-level move the 2018 >80%-hash attacker used.

Who this affects. Hobbyist operators running OFFd at home behind a residential router. Operator-controlled cluster nodes are not affected — they already configure -externalip= (LOCAL_MANUAL), which outranks LOCAL_UPNP in the score table and silently ignores the UPnP-injected address.

Status. UPnP remains enabled by default in v2.0.x. The default flip to -upnp=0 is planned for v2.1.0, matching the precedent of bitcoin/bitcoin#20410 (Bitcoin Core, 2020). This is a hardening recommendation, not a forced behavior change.

Full threat model and phased mitigation plan: issue #10.

Companion to the HTTP-discovery-path removal in PR #9 (merge 24196aa), which closed the larger sister surface (cleartext-HTTP IP discovery against amazonaws.com / ipify / icanhazip). PR #9 will ship in the next point release; the UPnP recommendation above applies to anyone already on v2.0.4 or v2.0.5.

Assets 6
Loading