[Proposal] Multi-Signer Chainstate Attestation Protocol for DigiByte UTXO Snapshots

[JohnnyLawDGB]

DIP Draft: Chainstate Attestation Protocol

  Title:    Multi-Signer Chainstate Attestation for DigiByte UTXO Snapshots
  Author:   DigiByte Community
  Status:   Draft
  Type:     Informational / Standards Track (Tooling)
  Layer:    Application / Node Bootstrap
  Created:  2026-04-09

Abstract

This proposal defines a community-driven protocol for producing, signing, verifying, and distributing DigiByte UTXO set snapshots to accelerate node bootstrapping. Snapshots are generated annually from block heights approximately one year behind the chain tip, then signed by a configurable threshold of trusted community members using DigiByte-native message signing. New nodes can verify signatures against a published signer registry and load the snapshot via existing Core RPC calls, reducing initial sync from days to minutes while still syncing the final year of blocks themselves.

Motivation

DigiByte has been operating continuously since January 2014. As of this proposal, the chain contains more than 23 million blocks representing over 12 years of transaction history. A new node syncing from genesis must:

• Download approximately 35 GB of block data
• Validate more than 50 million historical transactions
• Consume days of wall-clock time on typical consumer hardware
• Use significant network bandwidth, often exceeding monthly caps

This is an increasingly prohibitive barrier for new node operators. The cost compounds every year as the chain grows, directly opposing DigiByte's goal of decentralization through widespread node participation.

Centralized snapshot distributions exist informally but require trusting a single party. A formal protocol that distributes trust across multiple known signers, with cryptographic verification, addresses the root problem without introducing new trust assumptions beyond those already present in the network.

Specification

Overview

The protocol has four phases:

1. Snapshot generation — produce a canonical UTXO set at a chosen block height
2. Attestation collection — gather cryptographic signatures from trusted community members
3. Distribution — publish the snapshot and attestation file for download
4. Verification and loading — new nodes verify signatures and load the snapshot

Phase 1: Snapshot Generation

Cadence

Snapshots SHALL be generated once per calendar year. The nominal generation date is January 1st of each year, producing the annual snapshot for use throughout that year.

Target Block Height

The target block height for each snapshot SHALL be approximately one year behind the current chain tip at the time of generation. Specifically:

target_height = tip_height - (blocks_per_year)
blocks_per_year = (365 * 24 * 3600) / 15 = 2,102,400

The one-year maturity window ensures:

• Any reorgs, anomalies, or soft-fork activations have had ample time to resolve
• The target block is deeply buried and effectively immutable
• Signers have a full calendar year to independently verify before the next snapshot supersedes it
• Users bootstrapping from the snapshot still validate approximately one year of blocks themselves, maintaining their role as verifiers

The exact target height SHALL be the nearest multiple of 10,000 below the nominal tip - blocks_per_year calculation, to ensure signers can agree on a deterministic number.

Generation Command

Snapshots SHALL be generated using DigiByte Core's existing dumptxoutset RPC:

digibyte-cli dumptxoutset /path/to/digibyte-utxo-<height>.dat

The resulting file is a serialized UTXO set matching the specified block height.

Canonical Digest

A snapshot's canonical digest SHALL be the SHA-256 hash of the binary file:

digest = SHA256(snapshot_file_contents)

Phase 2: Attestation Collection

Attestation File Format

Each snapshot SHALL be accompanied by an attestation file in JSON format:

{
  "version": 1,
  "snapshot": {
    "filename": "digibyte-utxo-21181000.dat",
    "height": 21181000,
    "block_hash": "0000000000000000a1b2c3...",
    "size_bytes": 1234567890,
    "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "generated_at": "2026-01-01T00:00:00Z",
    "core_version": "v8.22.2"
  },
  "signatures": [
    {
      "signer_address": "D9DsDAyiLhkqgoXGk4dZrDbLVzrc8BrEQQ",
      "signer_identity": "Jared Tate",
      "signed_at": "2026-01-02T10:15:00Z",
      "signature": "H7J8K9...",
      "message": "DIGIBYTE-CHAINSTATE-ATTESTATION:21181000:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    }
  ]
}

Fields:

• version — Attestation format version (integer)
• snapshot.filename — Canonical snapshot filename
• snapshot.height — Target block height
• snapshot.block_hash — Block hash at the target height (retrieved via getblockhash)
• snapshot.size_bytes — Snapshot file size
• snapshot.sha256 — SHA-256 digest of the snapshot file
• snapshot.generated_at — ISO 8601 UTC timestamp of snapshot generation
• snapshot.core_version — DigiByte Core version that generated the snapshot
• signatures — Array of signer attestations

Signing Message Format

The canonical message that signers attest to SHALL be:

DIGIBYTE-CHAINSTATE-ATTESTATION:<height>:<sha256>

Where <height> is the decimal block height and <sha256> is the lowercase hexadecimal digest of the snapshot file.

This format is unique enough to prevent collision with other signed-message use cases and contains all data necessary to verify the attestation.

Signing Procedure

Signers SHALL use DigiByte Core's signmessage RPC with a DigiByte address they control:

digibyte-cli signmessage "D9DsDAyiLhkqgoXGk4dZrDbLVzrc8BrEQQ" "DIGIBYTE-CHAINSTATE-ATTESTATION:21181000:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"

The resulting signature is added to the signatures array of the attestation file.

Independent Verification by Signers

Each signer SHOULD independently:

1. Generate the snapshot themselves at the agreed-upon height using their own Core node
2. Compute the SHA-256 digest of their generated file
3. Verify the digest matches the published snapshot digest
4. Only then sign the canonical message

Signers who cannot independently generate the snapshot SHOULD NOT sign.

Phase 3: Signer Registry

A community signer registry SHALL be maintained as a separate canonical document:

{
  "version": 1,
  "updated_at": "2026-01-01T00:00:00Z",
  "signers": [
    {
      "address": "D9DsDAyiLhkqgoXGk4dZrDbLVzrc8BrEQQ",
      "identity": "Jared Tate",
      "role": "Core Lead",
      "added_at": "2026-01-01T00:00:00Z",
      "public_contact": "https://github.com/jaredr26"
    }
  ]
}

The registry is maintained via community consensus (e.g., a GitHub repository with pull requests requiring maintainer approval). Signers SHOULD be:

• Publicly identifiable community members with established reputation
• Capable of independently running a full DigiByte Core node
• Committed to independently verifying each snapshot before signing

Removal from the registry requires community consensus and SHOULD be documented with a reason.

Phase 4: Verification and Loading

Minimum Signature Threshold

Consumers of attested snapshots SHALL verify at least M valid signatures from the registry before loading a snapshot. The recommended minimum is M = 5 or M = majority of current registry size, whichever is greater. Consumers MAY require a higher threshold based on their own risk tolerance.

Verification Procedure

The verification process for a consumer:

1. Download the snapshot file and attestation file
2. Compute the SHA-256 digest of the snapshot file
3. Verify the digest matches snapshot.sha256 in the attestation
4. For each signature in the attestation:
   • Look up the signer address in the community registry
   • Reject signatures from addresses not in the registry
   • Verify the signature using verifymessage: the signer address, canonical message, and signature
5. Count valid, registry-matched signatures
6. If count ≥ M, the snapshot is considered attested

Loading the Snapshot

Once verified, the snapshot is loaded into DigiByte Core using loadtxoutset:

digibyte-cli loadtxoutset /path/to/digibyte-utxo-21181000.dat

After loading, Core will sync forward from the target height to the current tip using normal block-by-block validation. This final sync covers approximately one year of blocks (~2.1M) and takes a small fraction of the time required for a full genesis sync.

Prerequisite verification: This proposal assumes DigiByte Core supports loadtxoutset. If Core does not currently expose this RPC, a preliminary proposal to add it MUST be adopted first. The assumeutxo feature in upstream Bitcoin Core provides a reference implementation.

Reference Tooling

Three tools form the reference implementation:

1. Snapshot Generator (dgb-snapshot-gen)

• Runs alongside a trusted Core node
• Computes the target height from current tip
• Invokes dumptxoutset and captures the output file
• Produces the initial attestation file with snapshot metadata but no signatures
• Publishes the snapshot and empty attestation to the distribution channel

2. Signer CLI (dgb-snapshot-sign)

• Downloads a published snapshot and attestation
• Optionally regenerates the snapshot locally for independent verification
• Prompts the signer for their registered address
• Invokes signmessage to produce the attestation signature
• Publishes the updated attestation with the signature appended

3. Verifier/Loader (dgb-snapshot-load)

• Downloads the snapshot and attestation from a configured source
• Downloads the current signer registry
• Verifies SHA-256 digest
• Verifies all signatures against the registry
• Enforces the minimum threshold
• If all checks pass, invokes loadtxoutset on the target Core node

All three tools are standalone and do not require changes to DigiByte Core.

Rationale

Why annual snapshots instead of more frequent?
Annual cadence matches the operational reality: signers need time to independently verify, the community needs time to review the process, and the snapshot is used throughout the year rather than replaced constantly. More frequent snapshots fragment trust across too many artifacts. Annual snapshots are "events" the community can coordinate around.

Why one year behind the tip?
A year of maturity provides strong guarantees against reorgs, reorgs-triggered-by-soft-fork-activation, and any undiscovered anomalies. It also preserves the user's role as a verifier — anyone loading the snapshot still independently validates a year of recent history. Combined with existing consensus rules, this retains the security properties of a full sync while cutting the bootstrap cost by over 90%.

Why DigiByte address message signing instead of GPG?
DigiByte-native signing is accessible to any community member who runs Core. It doesn't require managing separate GPG keys, uploading public keys to keyservers, or trusting the web of trust. Signers sign with the same cryptographic identity they use on-chain, making the signer registry directly verifiable via the blockchain itself. GPG would add another key management burden with no corresponding benefit.

Why a community signer registry instead of hardcoded keys in Core?
A hardcoded signer set would require a Core release for any change to signer membership. A community-maintained registry allows flexibility, removal of compromised signers, and addition of new trusted members without blocking on Core releases.

Why the M-of-N threshold model?
Distributing trust across multiple independent signers prevents any single party — including a compromised "official" source — from producing a malicious attestation. Requiring multiple valid signatures means an attacker would need to compromise multiple independent parties simultaneously, which is significantly harder than compromising one.

Why start with community tooling rather than Core integration?
Ship, iterate, and refine before committing to Core changes. The protocol may need adjustments based on real-world operation (threshold values, registry management, snapshot format). Once battle-tested, specific primitives (perhaps a -attestedsnapshot flag that handles verification and loading automatically) can be proposed for inclusion in Core.

Backwards Compatibility

This proposal introduces no changes to the DigiByte consensus protocol or network protocol. It relies on existing Core RPC calls:

• dumptxoutset — present in current Core
• signmessage — present in current Core
• verifymessage — present in current Core
• getblockhash — present in current Core
• loadtxoutset — prerequisite verification required

If loadtxoutset is not present in the current Core release, a preliminary proposal to expose it is a prerequisite to this specification. This is a relatively small Core change with established reference implementations in upstream Bitcoin Core.

Security Considerations

Signer compromise. If a signer's key is compromised, the attacker can produce valid-looking signatures on malicious snapshots. The M-of-N threshold mitigates this — compromising one signer is insufficient. The registry MUST have a documented process for rapid signer removal upon disclosed compromise.

Registry compromise. If the signer registry itself is tampered with, an attacker could add malicious signer addresses. The registry SHOULD be distributed via multiple independent mirrors and ideally committed via a GitHub repository with signed commits. Consumers MAY pin specific registry versions.

Snapshot integrity. The SHA-256 digest binds the signature to a specific file. Any tampering with the snapshot file invalidates all signatures. Consumers MUST verify the digest before trusting any signature.

Chain state consistency. After loading a snapshot, Core continues sync from the target block. If the snapshot is valid but the subsequent sync hits a different fork than expected, Core's normal consensus rules prevail — the snapshot does not override consensus. The worst case is wasted time on the subsequent sync, not a compromised chain state.

Replay across networks. The canonical signing message MUST include a network identifier (implicit in the address prefix) to prevent testnet/mainnet snapshot replay. DigiByte mainnet addresses start with D, S, or dgb1; testnet addresses use different prefixes. Verification MUST enforce that signer addresses match the expected network.

Bootstrap regression. Consumers MUST retain the ability to sync from genesis. An attested snapshot is an optimization, not a replacement. If verification fails or no attestation meets the threshold, Core MUST fall back to a normal sync.

Long-term key rotation. Signers SHOULD be encouraged to rotate their attestation addresses periodically. The registry format supports tracking multiple historical addresses per signer identity.

Snapshot deprecation. Old snapshots SHOULD be marked as deprecated after a new annual snapshot is published, but consumers MAY continue to use older snapshots if they prefer. Attestations never "expire" — they remain valid evidence of the historical state at the time of signing.

Copyright

This proposal is placed in the public domain.

[JohnnyLawDGB]

Any concerns before I start building this out per the specs above?