Skip to content

Releases: hashburst/node-installer

HashBurst Node Installer v2.1.6

Choose a tag to compare

@hashburst hashburst released this 17 Aug 13:03
d031185

HashBurst Node Installer v2.1.6

Status: RELEASED.

Final field validation: PASS.
Network rollout validation: PASS.

Scope

v2.1.6 is a stabilization release focused on reinstall/upgrade correctness for full/blockchain nodes using HB-TEP behind NAT or dynamic addressing.

The release combines three narrowly-scoped fixes:

  • restart an already-running blockchain node after TEP/bootstrap environment preparation so systemd reloads EnvironmentFile;
  • repair incomplete runtime TEP identity by enriching missing stable peer_id and X25519 pubkey from the authoritative local /api/nodes registry while preserving mutable NAT coordinates;
  • reconcile the live TEP peer set with /api/nodes so a registered NAT node omitted by /api/tep/peers is restored instead of permanently discarded.

The runtime heartbeat path is hardened to fail closed when stable X25519 identity is unavailable instead of falling back to the host-local node.key.

Unchanged contracts

v2.1.6 does not intentionally change:

  • AES-256-GCM/X25519 cryptographic primitives;
  • heartbeat wire format;
  • authenticated NAT endpoint refresh semantics;
  • relay trust policy;
  • storage.summary relay scope;
  • HB-Files API behavior;
  • blockchain P2P transport;
  • replication enablement or UNPIN safety gates.

Field validation evidence

The first controlled node-7 lifecycle test validated the reinstall path: hashburst-node.service was already active and received a controlled restart after environment preparation; blockchain health returned; blockchain Peer ID, TEP node ID, TEP peer ID, TEP public key, reward address, wallet and persistent TEP key remained unchanged.

That first test also proved restart/reload alone was insufficient: node-7 remained peers_online=0/4 and received heartbeats were still dropped one-for-one.

Follow-up inspection identified the decisive runtime inconsistency on blockchainapi.one: /api/nodes contained the correct node-7 blockchain Peer ID and TEP public key while /api/tep/peers omitted node-7. Before reconciliation, dynamic TEP discovery recreated node-7 from its NAT address and the periodic blockchain peer sync removed it again.

The reconciliation candidate restored the registered peer from /api/nodes, preserved the authenticated public NAT endpoint 79.12.5.136:47777, and maintained the stable node-7 identities:

  • blockchain Peer ID 12D3KooWCkg4pM31Lzc4ZmAsJMFkW27escTNA9GwTTM8u8Q2T1b6;
  • TEP X25519 pubkey 4c7c258dd89a4b6e87fbe081077d6ed822d7e29df2760197b6edaa1a5a1ced10.

On the rendezvous, the validated state reached peers_total=4, peers_online=4, and pkts_dropped=0 while authenticated traffic continued. On node-7, the receive/drop pattern stopped being one-for-one, blockchain health remained status=ok, and the blockchain Peer ID remained unchanged.

Completed network rollout

The release runtime was then rolled out one peer at a time without restarting hashburst-node.service:

  • blockchainapi.one (64.31.4.9): 4/4 online, dropped=0;
  • node-6 (77.90.188.155): 4/4 online, dropped=0;
  • n4 (77.90.188.157): 4/4 online, dropped=0;
  • master-node (85.233.199.35): 4/4 online, dropped=0;
  • node-7 (observed NAT 79.12.5.136): progressed from 1/4 to 2/4, 3/4 and finally 4/4 as the remaining peers were upgraded.

The final node-7 status showed blockchainapi.one, node-6, n4, and master-node all online with their registered stable Peer IDs and TEP public keys. No rollback was required.

v2.1.6 runtime behavior

The runtime:

  • queries the local /api/nodes registry when a TEP peer is missing stable peer_id or pubkey;
  • fills only stable identity fields and does not overwrite mutable IP/UDP coordinates learned from authenticated traffic;
  • reconciles the runtime peer set against registered blockchain nodes when /api/tep/peers omits a registered NAT node;
  • preserves a previously observed NAT endpoint when restoring that peer;
  • requires a valid 32-byte X25519 public key before heartbeat encryption/decryption;
  • fails closed if identity enrichment is unavailable or invalid;
  • distinguishes missing identity, X25519 key-derivation failure and AES-GCM authentication failure in the journal;
  • keeps APP/relay authentication and transport policy unchanged.

Release gates

Completed before merge:

  • v2.1.2-v2.1.5 compatibility regressions green;
  • v2.1.5 installer/onboarding behavior retained;
  • fresh-install/reinstall identity preservation retained;
  • authenticated NAT runtime behavior retained;
  • v2.1.6 identity-enrichment and registered-peer reconciliation tests green;
  • v2.1.6 installer upgrade/idempotency sandbox green;
  • final v2.1.6 release contract green;
  • exact-head CI green after canonical version promotion;
  • field validation and five-node rollout green.

Version promotion and release

The canonical installer is VERSION="2.1.6" on main.

Release completed successfully:

  • PR #9 merged to main;
  • PR #10 retargeted, reviewed and merged to main;
  • final main commit verified at d031185e83dbbce805d31ae9317d0c8398a3cc90;
  • main-branch CI completed successfully;
  • annotated tag v2.1.6 created from the verified main commit;
  • GitHub Release v2.1.6 published;
  • GitHub source archives .zip and .tar.gz are available from the release.

HashBurst Node Installer v2.1.5

Choose a tag to compare

@hashburst hashburst released this 13 Aug 04:00
f36b94e

HashBurst Node Installer v2.1.5

Production-validated release for automatic HashBurst blockchain and TEP onboarding.

Highlights

  • Automatic HB-TEP onboarding with AES-256-GCM.
  • Stable blockchain P2P identity binding.
  • Persistent encrypted reward/signing wallet bootstrap.
  • Automatic blockchain BOOTSTRAP_PEERS configuration.
  • Automatic TCP/30307 blockchain P2P firewall rule when UFW is active.
  • TEP UDP/47777 onboarding and localhost-only status IPC on TCP/47778.
  • Canonical blockchain-based TEP discovery.
  • Relay disabled by default on ordinary nodes.
  • Edge nodes remain best-effort and non-committable.
  • Replication v2.1.3/v2.1.4 compatibility retained.
  • Installer reinstall preserves wallet, TEP identity and private swarm identity.

Production validation

Validated with:

  • blockchainapi.one / 64.31.4.9
  • master primary / 85.233.199.35
  • node-6 / 77.90.188.155
  • n4 / 77.90.188.157

Production validation confirmed:

  • master blockchain synchronization and NODE_REGISTRATION
  • stable P2P identity
  • TEP discovery with 3/3 infrastructure peers online
  • AES-256-GCM and app_ready
  • public TEP APP endpoint remains blocked
  • storage primary and ZFS preserved
  • replication and IPFS services preserved
  • /hashburst canonical redirect and final HTTP 200
  • private Kubo RPC :5011 remains unexposed

Release identity

Commit:

f36b94e

SHA256:

245b9ddff8538a303d75d605ccedd61316a24890e9101984a69cfe1849f85d42

HashBurst Node Installer v2.1.4

Choose a tag to compare

@hashburst hashburst released this 12 Aug 00:19
8497c6c

HashBurst Node Installer v2.1.4

v2.1.4 advances the native HashBurst replication controller from the v2.1.3 durable-replication foundation to a safe object-release lifecycle.

Safety defaults

  • Controller bind remains 127.0.0.1:8095 by default.
  • Controller mode remains observe by default.
  • Physical UNPIN requires controller HB_REPL_UNPIN_ENABLED=1.
  • The node agent independently requires HB_REPL_ALLOW_UNPIN=1.
  • Every destructive UNPIN also requires just-in-time authorization for the exact node, job, lease, CID and object generation immediately before local pin/rm.
  • Final logical release waits HB_REPL_DELETE_GRACE_SEC=900 seconds before an UNPIN can be scheduled.
  • The installer ships controller/agent units but does not automatically enable them.

Lifecycle additions

  • Durable logical-reference tombstones preserve idempotency after release.
  • Final release increments the object generation and marks existing replica desired state false.
  • Pending PIN/VERIFY work from older generations becomes stale.
  • Re-registration is rejected while an UNPIN has crossed the authorization boundary and its physical outcome is unknown.
  • Startup recovery converts an authorized-but-unconfirmed destructive operation into a verification path instead of assuming either success or failure.
  • Extra replicas can be trimmed only when the N total target and M committable minimum remain satisfied.

Packaging fix

hb_ipfs.py is installed into /opt/hashburst/replication/hb_ipfs.py as well as the HB-Files tree. This makes direct systemd execution of the replica agent self-contained and fixes the missing-module failure discovered during the v2.1.3 production rollout.

Failure domains

v2.1.4 adds persisted node metadata fields for failure_domain, provider, region, and rack. These fields are available for placement evolution and audit. They do not constitute a Byzantine proof-of-storage or a formal geographic durability guarantee.

Explicit non-claims

v2.1.4 does not implement controller HA/multi-writer consensus, Byzantine proof-of-storage, on-chain discovery, erasure coding, or a proof that independent failure domains are always available. A single active controller remains the supported topology.

Recommended rollout

  1. Upgrade controller code and schema while preserving the existing SQLite database backup.
  2. Start the v2.1.4 controller in observe with HB_REPL_UNPIN_ENABLED=0.
  3. Upgrade replica agents with HB_REPL_ALLOW_UNPIN=0.
  4. Validate continuous heartbeat and Kubo capacity reporting.
  5. Onboard the second committable node and validate real M=2 behavior.
  6. Move to pin-only and test a canary CID before broad PIN scheduling.
  7. Only after release/refcount/recovery tests pass in production, explicitly enable both UNPIN gates for a controlled canary release.

Never expose the private Kubo API (5011) publicly. Agents must use the local Kubo API only.

HashBurst Node Installer v2.1.3

Choose a tag to compare

@hashburst hashburst released this 11 Aug 07:11
021360d

HashBurst Node Installer v2.1.3

Durable replication foundation release.

Highlights:

  • native HashBurst replication controller
  • default replication policy N=3, M=2
  • committable and best-effort replica classes
  • 6-hour edge grace period
  • automatic repair and pin verification
  • outbound pull replica agent for NAT/intermittent nodes
  • SQLite desired/observed replication state
  • idempotent job leases and replay protection
  • optional HB-Files replication registration hook
  • replication services installed but not auto-enabled
  • automatic UNPIN remains disabled
  • controller default bind: 127.0.0.1:8095
  • existing port contracts preserved: 8093 mining, 8094 storage aggregator

Validation:

  • v2.1.2 regression: 12/12 PASS
  • existing release tests: 22/22 PASS
  • multipart regression: 1/1 PASS
  • replication tests: 31/31 PASS
  • v2.1.3 release regression: 22/22 PASS
  • Python syntax: PASS
  • shell syntax: PASS
  • SHA256SUMS manifest: PASS

Release asset SHA256:
c4f9019c97ede7264e794f318e1078a36395899175174620e8f6bb84d86bdaae

Operational note:
Replication services are intentionally not enabled automatically. Production rollout should begin in observe-only mode.

HashBurst Node Installer v2.1.2

Choose a tag to compare

@hashburst hashburst released this 10 Aug 23:00
862209f

HashBurst Node Installer v2.1.2 — GitHub-ready stable candidate

v2.1.2 is a safety/packaging release based on the production-validated v2.1.1 deployment.

Fixed

  1. Storage aggregator port safety

    • systemd unit now uses HB_AGGREGATOR_PORT=8094.
    • hb_aggregator_server.py now defaults to 8094.
    • unit sets HB_AGGREGATOR_TIMEOUT=3 to prevent an unreachable edge node from delaying the public aggregate for the previous 6-second default.
    • 8093 remains reserved for the mining aggregator.
  2. Fail-safe offline classification

    • online nodes derive capacity class from their validated role.
    • offline nodes use explicit configured capacity_class, then configured role.
    • an offline/unclassified node now reports capacity_class: "unknown"; it never implicitly becomes committable.
  3. Static node configuration clarity

    • example configuration includes explicit role and capacity_class for primary, secondary and edge nodes.
    • edge nodes should explicitly use role: "edge" and capacity_class: "best-effort".
  4. Explorer integration

    • adds an idempotent CSP-safe patcher for existing public explorers.
    • maps the storage panel to capacity_committable_gb and capacity_best_effort_gb.

Port contract

  • 8091 — storage node public summary (restricted to aggregator where directly exposed)
  • 8093 — mining aggregator
  • 8094 — storage network aggregator
  • 18094 — optional temporary dry-run port only

Production acceptance reference

Validated topology values remain:

  • committable: 5520 GB
  • reserved stakeholders: 3736 GB
  • free sellable: 1784 GB
  • offline edge contributes 0 GB to best-effort online capacity and never increases sellable capacity
  • unreachable edge timeout approximately 3 seconds