[Proposal] Standardized Configuration Profiles and Interactive Setup Assistant for DigiByte Core

[JohnnyLawDGB]

DIP Draft: DigiByte Core Configuration Profiles & Setup Assistant

  Title:    Standardized Configuration Profiles and Interactive Setup Assistant
  Author:   DigiByte Community
  Status:   Draft
  Type:     Informational / Standards Track (Tooling)
  Layer:    Application / Node Operation
  Created:  2026-04-09

Abstract

This proposal defines a set of standardized DigiByte Core configuration profiles targeting common node operation use cases, along with an interactive setup assistant that generates a tailored digibyte.conf file based on operator-provided hardware and purpose constraints. The profiles and assistant are initially distributed as community tooling alongside Core, with the possibility of future integration into the Core distribution.

Motivation

DigiByte Core exposes more than 50 configuration options. Defaults are conservative and safe, but rarely optimal for any specific use case. Operators currently face several recurring problems:

1. New users run nodes with default settings that are suboptimal for their hardware or purpose (e.g., running a mining node with only 450 MB dbcache, or an exchange service with maxconnections=125).
2. Experienced users reinvent the same optimizations across deployments, with no canonical reference.
3. Services layered on Core (DigiAsset Core, ElectrumX, block explorers, wallet backends) have implicit config requirements that aren't documented in one place.
4. Misconfiguration risks are common: exposing RPC to the public internet, running with insufficient mempool capacity, lacking indexes required by upstream services.

A standardized set of profiles backed by a guided setup tool reduces friction, reduces misconfiguration, and provides a single source of truth for "how to run Core for X".

Specification

Profile Definitions

Seven canonical profiles are defined. Each profile is a named configuration template with concrete values for the most impactful settings. Operators may start from any profile and customize further.

Profile	Purpose	Storage	RAM	Use Case
archival	Full historical node, serves peers	~35 GB + room to grow	4 GB+	Block explorers, researchers, long-term archive
pruned-standard	Pruned node, good balance	~10 GB	2 GB	Personal wallet, general use
pruned-light	Minimum viable pruned node	~3 GB	1 GB	Low-resource environments, SBCs
miner	Optimized for mining operations	~35 GB	4 GB+	Solo mining, pool nodes
exchange-service	Production service backend	~50 GB	8 GB+	Exchanges, custodial wallets, high-volume API
indexer	Full indexing for upstream services	~60 GB+	8 GB+	DigiAsset Core, ElectrumX, block explorers
dev-testnet	Developer/test environment	~5 GB	2 GB	Development, testnet, contribution

Profile Parameters

Each profile SHALL specify concrete values for the following parameters (where applicable):

Storage & Pruning

• prune — 0 (archival) or target MB
• dbcache — leveldb cache in MB
• maxmempool — mempool cap in MB

Indexing

• txindex — 0 or 1
• addressindex — 0 or 1 (where applicable)
• timestampindex — 0 or 1 (where applicable)
• spentindex — 0 or 1 (where applicable)

Networking

• listen — 0 or 1
• maxconnections — integer
• maxuploadtarget — MB/day or 0 for unlimited
• peerbloomfilters — 0 or 1
• bantime — seconds

RPC

• server — 0 or 1
• rpcbind — interface address
• rpcallowip — permitted source CIDRs
• rpcworkqueue — queue depth
• rpcthreads — worker thread count

ZeroMQ (service profiles)

• zmqpubrawblock — publisher endpoint
• zmqpubrawtx — publisher endpoint
• zmqpubhashblock — publisher endpoint

Reference Templates

Each profile SHALL have a corresponding reference template file named digibyte-<profile>.conf.example containing:

• The complete set of parameter values for that profile
• Inline comments explaining non-obvious choices
• Commented-out optional parameters relevant to the profile
• A header block identifying the profile name and version

Templates SHOULD be versioned alongside DigiByte Core releases to account for new parameters introduced in each Core version.

Setup Assistant

An interactive setup assistant SHALL be provided as a reference implementation. The assistant:

1. Asks the operator a series of questions (~8 questions maximum)
2. Maps answers to a profile and parameter overrides
3. Validates the resulting configuration for internal consistency
4. Writes the generated digibyte.conf to the appropriate datadir
5. Provides a summary of what was configured and why

Recommended question set:

1. What is the primary purpose of this node? (wallet / miner / exchange / indexer / dev / archive)
2. How much disk space can you allocate? (< 5 GB / 5-20 GB / 20-50 GB / 50+ GB)
3. How much RAM does this machine have? (< 2 GB / 2-4 GB / 4-8 GB / 8+ GB)
4. Will other services connect to this node locally? (yes / no)
5. Will this node serve peers on the public network? (yes / no)
6. Do you need historical transaction data for any address? (yes / no) — triggers addressindex
7. Do you need to look up any transaction by ID? (yes / no) — triggers txindex
8. Is this node running behind a firewall or NAT? (yes / no / unsure)

The assistant SHOULD default to the most restrictive/secure settings when an answer is ambiguous. RPC MUST default to localhost-only binding unless the operator explicitly opts in to remote access, in which case the assistant SHOULD warn about the risks and require a generated strong password.

Distribution

Initial distribution is via a community-maintained repository containing:

• profiles/ — Reference .conf.example templates for each profile
• setup-assistant/ — Reference implementation of the interactive tool
• docs/ — Detailed documentation of each profile and parameter

The repository is independent of DigiByte Core and tracks Core releases.

Rationale

Why profiles instead of per-parameter documentation?
Profiles capture the intent behind a configuration, not just the individual values. A user who wants to run a mining node benefits from having one canonical "miner" configuration rather than reading docs for 50 parameters and making judgment calls on each.

Why a separate tool instead of integrating into Core?
Ship and iterate faster. Community tooling can be refined without going through Core's release cycle. Once the profiles and assistant have been validated through real-world use, specific primitives (template files, profile flags) can be proposed for inclusion in Core in a later release.

Why the specific profile set?
The proposed profiles cover the dominant real-world use cases observed across the DigiByte ecosystem: wallets, mining operations, exchange backends, indexing services, and development environments. A smaller set is preferred over exhaustive coverage to reduce confusion.

Why an 8-question limit for the assistant?
Research on onboarding flows suggests completion rates drop sharply beyond ~10 questions. The 8-question limit keeps the assistant usable while collecting enough information to select a profile and the most impactful overrides.

Backwards Compatibility

This proposal introduces no changes to DigiByte Core. The profiles use existing configuration parameters and the assistant generates standard digibyte.conf files that Core already supports.

Future work may propose:

• Adding the reference templates to Core's contrib/ directory
• Adding a -profile=<name> command-line flag to digibyted that loads a named profile
• Integrating the assistant into the Core release process

These are explicitly out of scope for the initial proposal.

Reference Implementation

A reference implementation will be provided in a community-maintained repository containing:

1. Profile templates — Seven .conf.example files, one per profile
2. Setup assistant — A CLI tool (Python or Node.js) that implements the question flow and generates configs
3. Documentation — Per-profile rationale, parameter explanations, and troubleshooting guidance

The reference implementation will target the current DigiByte Core release and be updated as new Core versions introduce configuration changes.

Security Considerations

Default-deny for network exposure. The assistant MUST NOT generate a configuration that exposes RPC beyond localhost without the operator explicitly opting in and understanding the implications. When remote RPC is enabled, the assistant SHALL:

• Generate a cryptographically strong rpcpassword using the operator's OS-native randomness
• Set rpcbind to a specific interface rather than 0.0.0.0
• Require explicit CIDR values for rpcallowip
• Display a security warning summarizing the exposure

Profile integrity. Reference templates SHOULD be distributed with accompanying SHA-256 hashes and ideally GPG signatures from the maintainer. The setup assistant SHOULD verify template integrity before use.

Parameter drift. As Core adds or changes parameters between releases, stale profile templates may produce invalid configurations. Profile templates MUST declare which Core version they target, and the setup assistant MUST warn if the target version differs from the installed Core binary.

No secret storage. The assistant MUST NOT persist generated passwords or credentials anywhere except the generated digibyte.conf. Operators are responsible for securing the resulting file with appropriate filesystem permissions.

Copyright

This proposal is placed in the public domain.