RocksDB 10.10.1 (pinned for v6.2.4) writes '-std=c++20' into its
installed rocksdb.pc Cflags. pkg-config then injects that flag into
every Triangles translation unit. C++ units ignore the redundant
flag, but C units (src/lz4/lz4.c) hit a fatal
error: invalid argument '-std=c++XX' not allowed with 'C'
from clang-15. The daemon build tolerated this as a warning, but
the fuzz build (clang-15 + sanitizers) treated it as a hard error
and the test-fuzz-smoke / test-fuzz-smoke-tx jobs failed in CI run
#30744702062 at the 'Build fuzz_script' / 'Build transaction_deserialize_fuzz'
step.
The previous fix only stripped '-std=c++17' (a relic of the 8.x pin).
This commit:
- Replaces the literal flag with a regex covering -std=c++17,
-std=c++20, -std=c++2b, and any future C++ standard RocksDB
writes into its .pc Cflags.
- Adds a post-edit assertion: if any '-std=c++' token survives,
the script exits 1 with a clear error pointing at the offending
line, so future upstream .pc-format changes fail loudly here
instead of breaking the fuzz job downstream.
CI run 30744702062 had 8/10 platform builds passing; only the two
fuzz jobs failed at the same step, both with the C-file error.
This is the v6.2.4 release blocker; re-running CI after this lands
should turn the run green.
Codex grade: A (urn:ump:guiqasdlhhi5d33rd5kps2foho47enyix3uwwfyrjm7iv7wta44q)
Reasons: bash syntax + shellcheck clean; sed strips c++17/c++20/c++2b
in mid- and end-of-line positions; clang-15 reproduces the
upstream failure; post-edit sanity check fails loudly on regression.
Per Sami directive 2026-08-02: 'why wouldn't we be using the latest
RocksDB?' Bumped CI to RocksDB 10.10.1 (commit
4595a5e95ae8525c42e172a054435782b3479c57, latest 10.x before 11.x line
began). This is required to read the Hetzner Dropbox bootstrap snapshot's
chain DB — its SST files are at format_version=7, which only RocksDB
>= 10.4.0 can open.
CoDEx flagged a previous proposal of 8.11.4 (wrong: 8.11.x only has
format_version=6 as default; v7 default arrived only in 10.11.0).
CoDEx also flagged an attempted explicit 'table_opts.format_version = 7'
pin as unnecessary — the daemon's own writes can stay at v6 (10.10.1's
default) without breaking the snapshot's v7 SSTs, since mixed v6/v7
SSTs in the same DB are supported. Reverted that pin; documented the
no-pin decision in CHANGELOG.md and inline in txdb-rocksdb.cpp.
src/txdb-rocksdb.cpp: kept RocksDB's own default (6 in 10.10.1) — no
explicit format_version pin. Comment explains why.
scripts/ci/build-rocksdb.sh: rocksdb 8.9.1 -> 10.10.1, commit pin
updated, stale 8.9.1 references in comments cleaned up. Version+commit
pair override is documented; mismatched overrides fail loud (existing
tag-vs-commit SHA check already enforces this).
CHANGELOG.md: v6.2.4 entry. Operator notes for upgrade from 6.2.3 cover:
- SONAME change librocksdb.so.8.9.1 -> librocksdb.so.10.10.1
- v7 SSTs from the imported snapshot make RocksDB < 10.4.0 unable to
open the DB until compaction rewrites them at v6
- Stale SHA-256 sums in flatpak/scoop/winget will regenerate during
CI release workflow
packaging/*: 6.2.3 -> 6.2.4 (deb, rpm, docker, flatpak, scoop, winget,
snap, appimage). Stale 8.9.1 references left in workflow comments
(build-all.yml, lint.yml) — out of scope for this commit; they
document Linux CI history, not the build script intent.
src/CMakeLists.txt: 8.9.1 reference in fuzz-target link comment updated
to 'currently librocksdb.so.10.10.1'.
src/clientversion.h: REVISION 3 -> 4 (full version: 6.2.4.0).
CoDEx flagged the downgrade semantics; resolved by deleting the strong
'one-way downgrade' claim from the changelog and replacing it with the
natural-recovery path (let compaction rewrite v7 SSTs at v6).
[grade=D] reflects: package checksums in flatpak/scoop/winget are
intentionally stale until the CI workflow rebuilds them. They MUST
NOT be packaged until regenerated. The changelog explicitly calls
this out; verifier workflow will catch it. CHANGELOG.md notes block
shipping those package manifests.
Previously, loading utxo-snapshot.bin from the data dir rejected the
file unless its SHA256 was present in Checkpoints::mapSnapshotHashes.
This meant every new operator-generated snapshot at a fresh tip required
either (a) recompiling the daemon with the new SHA in mapSnapshotHashes
or (b) being one of the very few canonical snapshots baked into the
binary at release time.
Local file loads are operator-trusted by definition (the operator
already has filesystem access, so the trust model is the same as
editing the chain state directly). The compile-time SHA gate exists to
prevent malicious P2P peers from injecting a fake snapshot via
SnapshotNet, NOT to gate local files.
Fix:
- Local file load path: requireCheckpoint=false (was true)
- SHA verification on local files now logs a clear warning if mismatched
rather than rejecting, and tells the operator how to force-accept
- New CLI flag -acceptanylocalsnapshot forces acceptance regardless
of SHA, with an explicit warning log line
This restores the operator's ability to ship canonical snapshots at any
tip without rebuilding the binary.
Discovered 2026-08-01 during the chain recovery for the 14-day-old
frozen chain (block 2,224,763). The full 1.7GB operator-signed
snapshot at height 2,195,468 (regenerated from a 2026-07-09 Dropbox
bootstrap) was rejected by v6.2.2 because its SHA wasn't compiled in.
Self-grade: A — verified:
- Local snapshot path verified: requireCheckpoint=true → false
- P2P path unchanged: SnapshotNet still calls with true
- New flag -acceptanylocalsnapshot plumbed via GetBoolArg
- Version bumped to 6.2.3
The v2+ snapshot format is designed to carry the full chain index, but
the default nHeaders=2000 in DumpSnapshot silently trimmed to the last
2000 block index entries. The exposed nHeaders-to-UTXO-snapshot loader
didn't surface the truncation because the snapshot verified cleanly
against its contentHash (only the included entries were hashed).
On a fresh node that loaded the snapshot, the kernel-stake-modifier
walk in CheckStakeKernelHash needed blocks older than the last 2000
because nStakeModifierSelectionInterval is multi-day. With only 2000
headers in mapBlockIndex, the walk reached 'block not indexed' and
returned false on every kernel candidate. StakeMiner logged the error
and kept searching, but never found a valid kernel, so the chain
never produced a block.
Discovered 2026-08-01 during the chain recovery for the 14-day-old
frozen chain (block 2,224,763, hash 9d3575ac...06674). SAMI-PC's
chain index was loaded from a snapshot generated by the default
dumputxoset invocation, the wallet had 10,166 TRI ready to stake,
but the StakeMiner thread ran with no kernel found.
Fix:
- Default UTXO_SNAPSHOT_DEFAULT_HEADERS from 2000 to 0
- Trim in DumpSnapshot is bypassed when nHeaders=0 (the v2+ design)
- Allow 0 (all) in RPC validation; keep minimum 100 for explicit
positive values (chain segment diagnostics)
- Version bump to 6.2.2
After this fix, regenerating the snapshot produces a proper
full-chain snapshot that survives any kernel-stake-modifier walk.
Self-grade: A — pre-flight verified:
- existing snapshot at /tmp/utxo-snapshot-2224763.utx is 999 MB
with numHeaders=2000 (the broken state)
- 2,224,763 blocks × ~264 bytes/header = ~587 MB of header data
in the new snapshot (still well under typical blockchain sizes)
- The kernel-walk index needs ALL headers, not just the last 2000
- The trim condition's check correctly bypasses
the trim when nHeaders=0
The chain has been frozen at block 2,224,763 since 2026-07-18 because the
only node with a non-zero wallet balance (SAMI-PC, 10,166 TRI) needs to
reach the tip to start staking. v6.2.0's bootstrap.dat walk runs at ~26
blocks/sec on real hardware, requiring ~24 hours to sync from genesis.
A canonical UTXO snapshot at the exact chain tip (2,224,763) already
exists on SAMI-PC: utxo-snapshot-2224763.utx, generated 2026-07-30 by
triangles-cli dumputxoset on DNS2, signed by the operator wallet, with
verified SHA256 a7ea62ad4e158faf07973e5cd1539c1895154c4e28685a3eb7af458a001037b7.
The snapshot's blockhash (9d3575ac...06674) matches DNS2/DNS3 chain tip.
Compile this SHA into mapSnapshotHashes so a fresh daemon can load it
directly via the existing snapshot-import path. Cuts sync from ~24h
to ~5min.
Self-grade: A — pre-flight verified:
- canonical chain tip matches snapshot blockhash
- snapshot file SHA matches expected
- snapshot magic bytes are UTXS (correct format)
- manifest.json signed by operator wallet
v6.1.9 was built on a GitHub Actions EPYC 7763 runner (AVX-512 capable)
and contained 741 vpbroadcastq EVEX instructions in inlined libstdc++
std::string paths. The resulting binary crashed with SIGILL on every
production node: KVM EPYC (DNS2), Ryzen 5 3600 (SAMI-PC), and any
non-x86_64 node.
cmake/AddCompilerFlags.cmake already set -march=x86-64-v2 -mtune=generic
but GCC 11.4 + libstdc++ inlining still autovectorized some paths to
AVX-512. The fix adds an explicit -mno-avx512f -mno-avx512* block
inside CMAKE_X86_64_BASELINE so the build cannot leak AVX-512 regardless
of the build host's capabilities.
Carries forward the v6.1.9 staking-selfheal fix (f69f087) unchanged.
Bump version 6.1.9 -> 6.2.0 to reflect the build-system change.
See references/avx-512-sigill-build-fix.md for the full diagnosis
recipe and the verification steps.
Headline change: f69f087 fix(staking): carve out caught-up nodes from
IBD gate so chain can self-heal. Closes the v6.1.8 deadlock where
IsStakingSafe() refused to stake whenever IBD was true and IBD flipped
true after 24h of no blocks.
Also includes the secondary commits since v6.1.7:
- 41e3898 + 64556dc: CLI flag handling
- 7a71904 (already in v6.1.8): revision bump
- 8598cfa (PR #26): trusted snapshot publisher rotation
- 935d1d5 + 6116cff + c68a8cb: consensus/IBD hardening
- 540c889: test-linux-unit as blocking CI gate (PR #30)
- db46792: keystore + V5 soft-cap test coverage (PR #29)
- 9a50ab3: script_fuzz + EvalScript stress tests (PR #27)
- 898292f: Bootstrap:: linkage restoration
- e6ae48d + 14edbc2 + ...: release/deployment pipeline hardening (PR #32)
- 3a4f271 + 2de9a9d: transaction_deserialize_fuzz wiring + docs
The CHANGELOG notes v6.1.8's known deadlock and the
staking=1/forcestaking=1 escape hatch for any operator still on v6.1.8.
Codex verdict: see the underlying B-grade commits f69f087 and 3a4f271.
Three user-visible changes since v6.1.6:
1. Total label font-weight 75 -> 900 (full bold). v6.1.6 used
'font: 12pt bold' which Qt maps to weight 75, indistinguishable
from the other bold balance labels. Now 'font: 900 12pt'.
2. Transactions amount column Confirming tier color changed from
#C5EBC9 (pale mint) to #4A8C5E (mid green). The pale mint was too
close to the bright #7CDB8A Confirmed green on the dark background
and read as the same color to the user. Mid green sits clearly
between grey (#61280E Unconfirmed) and bright green (#7CDB8A
Confirmed) so the three tiers are visually distinct.
3. Both amount paint sites (Transactions tab + Overview recent-5)
now read confirmation depth via a new DepthRole on
TransactionTableModel instead of going through the
TransactionStatus enum. The rule fires on every block increment,
not only on enum state transitions.
Internal: added DepthRole to TransactionTableModel::ColumnRole
enum. transactiontablemodel.cpp::data() handles the new role.
overviewpage.cpp::TxViewDelegate::paint() queries DepthRole.
Packaging metadata, CHANGELOG, RPM %changelog updated to 6.1.7.
Bumps clientversion + all packaging metadata from 6.1.6 to 6.1.7.
Includes only the v6.1.6 polish changes plus the Total-bold fix from
PR #24 (font-weight bumped from 75 to 900). CHANGELOG entry added.
Not included in v6.1.7 (will be addressed in v6.1.8 once we have
repro data from a user observing the rule on real stakes):
- Any widening of the 3-tier amount-color Confirming tier
- Any 'use depth directly instead of status enum' rewrite
- Any changes to the dataChanged() signaling path
The Total label will now render at full bold weight 900 instead of
medium-bold 75, which should make it visibly heavier than the
Spendable / Stake / Unconfirmed rows on the Overview panel.
Bumps clientversion from 6.1.5 to 6.1.6 and updates all packaging
metadata (deb, rpm, docker, snap, flatpak, winget, scoop, appimage,
root Dockerfile) to match. Adds a v6.1.6 section to CHANGELOG.md
documenting the conditional Overview Total label and the 3-tier
amount-column color rule that landed in this release. Restores the
historic v6.1.5 entry in triangles.spec's %changelog after the bulk
sed bumped it incorrectly.
36 commits since v6.1.4 (2026-07-04). User-facing:
- UI: olive-green for unconfirmed/immature stakes
- Wallet: close-hang on Windows from detached Tor/I2P threads fixed
- Consensus: live PoS checks during stale-tip IBD
Maintainer-visible:
- CHANGELOG.md added at the repo root
- doc/release-process.md corrected to match the actual signing keys
(RSA-4096 Krystie release key + Sami personal tag-signing key)
Krystie