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.
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.
The RPM spec had no %changelog section, so 'rpm -q --changelog triangles'
returned nothing and downstream tooling (dnf/yum repoclosure, COPR
audit) flagged the package as low-quality. Add entries for the 6.x
release line (6.1.5, 6.1.4, 6.1.3, 6.1.1, 6.1.0) and 5.3.7.
Skipped v6.1.2: that release was yanked (5c312bb published 2026-07-01,
superseded by 6.1.3). Including it would mislead anyone searching the
changelog for the actual v3-snapshot fix.
Dates match git tag dates. Maintainer identity uses the project email
sami@cryptographic-triangles.org (matches other release metadata).
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)
SQLite wallet (default), RocksDB chaindb (default), Boost removal
from common link, I2P startup performance fix (180s→27ms).
Migration is automatic and non-destructive:
- Wallet: BDB → SQLite on first open (original preserved as .bdb.bak)
- ChainDB: LevelDB → RocksDB on next start (via -chaindb flag)
Every Triangles wallet is now a Tor node. Staking rewards subsidize
Tor infrastructure.
Core changes:
- Embedded Tor 0.4.9.6 as git submodule
- ConnectNode rejects all non-.onion peers
- Tor failure is fatal - wallet requires Tor to operate
- All proxies forced through embedded Tor SOCKS
- Clearnet (IPv4/IPv6) disabled at startup
- HTTP seed fetch routes through Tor proxy (removed boost::asio dep)
- Merged PoW cleanup: -623 lines of dead mining code
- Stripped dead LEGACY/MIXED bootstrap modes from net_bootstrap
- RPC getnetworkinfo reports tor_native mode
Tooling:
- scripts/bump-version.sh syncs version across all 17+ files
- Version bumped to 5.6.0 across all packaging manifests
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Single command to update version across all 12+ files:
scripts/bump-version.sh 5.7.0
Updates: clientversion.h, version.h, triangles-qt.pro, Dockerfile,
and all packaging manifests (Docker, AUR, Chocolatey, Debian, RPM,
WinGet, Homebrew, Nix, AppImage).
Sync fixes:
- Extend stall detection beyond IBD to catch post-IBD sync gaps
- Walk-forward inv continuation to avoid CBlockLocator exponential gap loop
- Track walk-forward progress for stall recovery without restarting from scratch
GUI fixes:
- Load transactions synchronously in constructor (deferred QTimer never fired)
- Use beginResetModel/endResetModel instead of deprecated reset()
- Schedule full refresh on TRY_LOCK failure to avoid dropped CT_NEW notifications
- Only update cachedNumBlocks after successful balance check (prevents permanent loss)
- Add GetAllBalances() single-pass balance retrieval with TRY_LOCK
Bootstrap:
- Add trusted snapshot manifest verification for bootstrap archives
- Add IsKnownCheckpoint() to validate manifest against compiled-in checkpoints
- Skip txleveldb rebuild when verified manifest is present
Bump version to 5.3.7 across all packaging manifests.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- AUR PKGBUILD: v5.3.6, new asset URLs, verified SHA256
- Chocolatey: v5.3.6 nuspec + install script with new zip URL/hash
- Winget: v5.3.6 multi-file manifest format
- Nix: v5.3.6 derivation with updated fetchurl hashes
- RPM: v5.3.6 spec + build script with new binary names
- Debian: v5.3.6 control + build script
- AppImage: v5.3.6 build script with new download URL
- Scoop: new bucket manifest (JSON) for Windows
- Docker: new Dockerfile + docker-compose for headless node
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Bump version 5.1.4 → 5.1.5 across all source, CI, and packaging files
- Remove 157 build artifacts (build/*.o, release/*.dll, etc.) from git tracking
These were added before .gitignore existed and caused cross-platform CI failures
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- GitHub Actions workflow builds DMGs for both Intel and Apple Silicon
- Update .pro file: macOS 11+ target, Homebrew paths instead of MacPorts
- Add RPM spec + build script for Fedora/RHEL/openSUSE
- Add Nix derivation with autoPatchelfHook
- Update Homebrew formula to support macOS (Intel + ARM64)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Krystie
sami7777