Frequently Asked Questions
Short answers for operators and developers. Project positioning (Bitcoin Commons narrative, governance framing): thebitcoincommons.org FAQ.
Governance philosophy and tier mechanics: Governance Overview and Governance Model.
General
What is BLVM?
BLVM (Bitcoin Low-Level Virtual Machine) is compiler-like infrastructure for Bitcoin: the Orange Paper spec, blvm-consensus, blvm-protocol, blvm-node, and blvm-sdk. See Introduction.
Is this a fork of Bitcoin?
No. BLVM does not fork Bitcoin’s chain or consensus rules. It implements the same consensus rules as mainnet Bitcoin.
Is the system production ready?
BLVM publishes a full node stack, crates, tests, and formal verification tooling, but readiness depends on your deployment: apply your own security review, RPC hardening, and monitoring. Governance enforcement is not universally activated (test keys in default deployments). See Deployment posture and System Status. “Artifacts exist” is accurate; “production mainnet node with live governance” is not yet.
Where is the code?
Repositories under BTCDecoded (e.g. blvm, blvm-node, blvm-consensus). The umbrella release binary is built from the blvm crate.
Running a node
How do I install BLVM?
Pre-built packages and binaries: btcdecoded.org/install (current release). Platform/feature notes: Installation. Verify checksums on every download.
How do I run my first node?
Quick Start (regtest, ~5 minutes) or First Node Setup (config file; mainnet IBD for first sync).
What must I do before mainnet?
See Deployment posture: RPC auth, bind addresses, release verification, backups, and module supply chain.
How do I configure the node?
blvm.toml, CLI flags, and BLVM_* environment variables. Precedence: CLI > ENV > file > defaults. Node Configuration, Configuration Reference.
Can I start from an existing Bitcoin Core datadir?
Yes, with the rocksdb feature (blvm default features; portable Windows/aarch64 release builds use redb/sled instead): stop bitcoind, point --data-dir at a synced Core tree, migrate once to <datadir>/blvm/. See Operations: Core datadir.
What storage backends are supported?
database_backend = "auto" (usually heed3 in default builds), or explicit rocksdb, redb, sled, tidesdb. See Storage Backends.
What experimental compile-time features exist?
Stable GitHub Releases ship platform-specific feature sets (see Release process: Build variants). blvm default features (local cargo build and Linux x86_64 release artifacts) include Dandelion++, Iroh, UTXO commitments, BIP70/REST, and compression; portable Windows and Linux aarch64 release CI builds omit several of those. BIP119 CTV, Stratum V2 node demux, sigop counting, and Quinn still often need explicit --features. See Installation: experimental variant.
What RPC methods are available?
JSON-RPC aligned with common Bitcoin node docs, plus BLVM-specific and module-extended methods. See RPC API Reference and the parity table there.
How do I troubleshoot?
Appendix: Troubleshooting. Mainnet IBD: Troubleshooting: Mainnet IBD.
Governance
Questions operators and new contributors often ask before reading the full governance docs.
Do I need governance to run a node?
No. Running a BLVM node does not require tiers, multisig, or governance tooling. Use the Operator guide and Deployment posture. Governance applies when you contribute code, review PRs, or sign releases.
What is Bitcoin Commons vs BLVM?
BLVM is the technical stack (spec, node, SDK). Bitcoin Commons is the governance framework (tiers, signatures, fork rules). They are related but serve different roles. See Governance Overview.
What are layers, tiers, and signatures?
Layers map repo areas (consensus, protocol, node, modules). Tiers set how many signatures a change needs. Signatures are cryptographic approvals from registered keyholders. Constitutional layers need more signatures than extension layers. Details: Governance Model, Layer-Tier Model.
Why “6x harder to capture”?
Bitcoin Commons applies graduated signature thresholds and review periods so capturing governance requires compromising many independent keyholders across layers, not a single maintainer group. See Governance Model.
Modules and development
How does the module system work?
Optional features run in isolated processes with IPC. See Module catalog and Building modules.
Can I build my own module?
Yes. Start with Building your first module, then Building modules.
How can I contribute?
Contributing, Contributing to Documentation.
What documentation should I read?
Use the Introduction: Who is this for paths. Operators: Getting Started + Node + Security. Developers: SDK + Modules. Researchers: Orange Paper + Formal Verification.
Spec and verification
What is the Orange Paper?
The normative mathematical specification of Bitcoin consensus (implementation-agnostic IR). Hosted on thebitcoincommons.org; in-book digest: Orange Paper.
What is the primary verification artifact?
The Orange Paper is the normative spec. Spec-lock, differential testing, fuzzing, and proptest enforce alignment with it; they do not replace it. Details: Formal Verification.
Is formal verification “proof instead of testing”?
No. Rust + Tests + Math Specs = Source of Truth. See Formal Verification and Differential Testing.
Does spec-lock prove constant-time cryptography?
No. Spec-lock checks consensus conformance on public inputs; secret-path timing is blvm-secp256k1. See Formal Verification → What formal verification delivers.
How does formal verification work?
BLVM Specification Lock binds #[spec_locked] functions to Orange Paper contracts; Z3 checks obligations on merge. Formal Verification, verification policy.