Bitcoin Commons / BLVM

What we've been working on in BLVM, Oct 20 to Nov 10, straight from the commit log 🤓 GPU. The release binary includes CUDA batch signature verification for ECDSA and Schnorr. On a machine with an Nvidia device, IBD runs on the GPU. On a machine without one, the binary falls back to CPU automatically. No recompile, no flags. Proofs. Lean now checks the Orange Paper model beside Z3. The subsidy theorem is proved in both Rust and Lean, and a growing set of Orange Paper sentences carry Lean proofs. Privacy. Dandelion++ transaction relay is on by default. Stem paths are randomized at peer handshake, and each transaction draws its own fallback deadline from a jittered window so there's no fixed timing signal an observer can use to work back to the origin. Fees. The node ships a full fee estimator with history, block projection, and mempool blending. External fee sources register by name and the operator picks the active one in config. The new fee module pulls from upstream sources and pushes a blended table into the node. Timers. Modules schedule work through a node-owned timer service: once and repeating timers, cron, chain triggers, and durable timers that survive a module kill. Networks. Testnet4 and Signet are both supported on the command line. Migration. For anyone running Core: BLVM reads bitcoin.conf directly, honors your existing config, and starts up storage-aware. The data directory is locked on startup. Modules. The registry covers wallet and address history, payment processing, miniscript analysis, ZeroMQ notifications, governance signaling, and selective sync. Each runs as its own process. Modules never open sockets directly. The node runs the network on their behalf, and the operator controls which hosts each module can reach. Consensus. We keep closing places where the implementation accepted what Bitcoin rejects. CSV and CLTV now activate at their correct heights. Version-0 witness programs of the wrong length are rejected at decode. The old 10,000-transaction block cap is gone. Releases. Nothing is built by hand. Tests, clippy, a security audit, fuzzing, spec-lock, deterministic Linux builds, attested binaries, and deb, rpm, Arch and Windows packages all come out of workflows. Linux aarch64 ships, so Raspberry Pi 64-bit is a supported target. The Orange Paper is the spec. BLVM is the first implementation. No new coin. 🧡 thebitcoincommons.org

Bitcoin lets you verify the money without trusting a bank. The software that runs it still mostly asks for trust, because a small group decides what goes in and everyone else runs what they ship. We're building a second node where the rules are written in plain math anyone can read, and the code is checked against them every time it changes. If the code drifts from the rules, the check fails. It's early and not for real money yet. The point is that "don't trust, verify" should cover the software too. No new coin, just a clearer way to check the one we have.

Why BLVM being independent matters 🧡 The BLVM node is built from the ground up. It doesn't use Core code and it doesn't use the rust-bitcoin bitcoin crate. Consensus is written from the Orange Paper, a plain mathematical spec of Bitcoin. Here's what that gets you. A real second opinion. We run Core's own test vectors against BLVM, and every difference gets run down. Recently that closed gaps in script handling, the mempool and block templates. A second implementation written from a spec is the best way to check that the rules are written down clearly enough for anyone to follow. Proofs that belong to the spec. Our Z3 and Lean checks verify the Orange Paper's model, so they don't depend on any one codebase. Any implementation that matches the spec benefits. One spec. Independent implementations. No new coin. thebitcoincommons.org

A few things about BLVM we haven't talked about yet 🤓 Privacy. Dandelion++ changes how your node announces a transaction. It passes it quietly along a random chain of peers first, and then one of them broadcasts it to everyone, so the broadcast no longer comes from the node that created it. It's on in the default release build. Works with your tools. Bitcoin-style JSON-RPC, ZMQ notifications, and Electrum and Esplora serving from the wallet index. blvm config convert-core turns a Core bitcoin.conf into a BLVM config. Modules. Optional features run as separate sandboxed processes. Miniscript and PSBT analysis, ZMQ, a wallet index, payments, and selective sync are all modules. Sync. LMDB with zero-copy UTXO reads is the default storage on the IBD hot path, the backends are swappable, and IBD resumes from a UTXO snapshot. Mempool. Four RBF modes and five eviction strategies, all configurable. Install. Docker images, a nightly channel, and builds for Linux x86_64 and aarch64 and for Windows, with deb, rpm and Arch packages and checksums on every release. The Orange Paper is the spec. BLVM is the first implementation. No new coin. 🧡 thebitcoincommons.org

Interested in joining the discussion? Spec questions, BLVM testing, Orange Paper review, all of it happens here. t.me/+DyQgnUc-iRs1ZTQx

What we've been working on in BLVM, Sep 20 to Oct 19, straight from the commit log 🤓 Spec. The Orange Paper gained parseable formulas for CSV and locktime sign handling, header time strictly over the median, minimal BIP34 height pushes, BIP54 coinbase locktime of height minus one, BIP94, and the witness commitment shape. Every new consensus check now gets a spec-lock row: an unpatched UNSAT case, so any later edit that drops the check fails the lock. Spec text, Rust implementation, and Z3 check move together. Consensus. blvm-consensus went from v0.1.44 to v0.1.61 across 17 releases. Most of the fixes close places where the implementation accepted what Bitcoin rejects: BIP68 relative locks at connect, header bits against the ancestor window, witness commitments, duplicate coinbases after height 91722, non-push P2SH scriptSigs, and nested P2WSH multisig signature order. We'd rather find and publish these than leave them in. Node and wire. Witness stacks now survive relay and compact blocks, the 10,000 transaction block cap is gone so weight decides, reorgs walk to the real fork, and verifychain and ping RPCs work as documented. blvm-node is at v0.1.73. Testnet4. Supported end to end since Oct 7, from network id and genesis through consensus rules and the blvm command line. Testing. Script verdicts are compared with libbitcoinconsensus in CI, including invalid scripts that never appear on chain. Property tests now call production code instead of checking their own assertions. Tooling. The blvm-ui console can now install and run a node. It downloads the official release, checks it against checksums.sha256, and generates RPC credentials. Everything above is released. The Orange Paper is the spec. BLVM is the first implementation. No new coin. 🧡 thebitcoincommons.org

A Bitcoin implementation is not Bitcoin itself. The protocol is defined by the rules its participants enforce, not by the authority of a particular repository. Implementation diversity matters. Independent verification matters more.

The terminal was never the product. Bitcoin infrastructure should be sovereign enough for cypherpunks and simple enough for everyone else. One of our contributors, Camilo has been cooking on an optional UI for our BLVM node at @BTCCommons. Run it. Watch it sync. See your peers. Validate Bitcoin. We’re not just building another implementation. We’re making independent verification usable.

It's one thing to create a technical curiosity. It's another to build a stack that secures Bitcoin for the next 500 years.

Bitcoin development requires AI tools that actually understand Bitcoin. Not just the codebase. The debates behind it, the proposals that failed, the arguments that shaped the protocol, the precedents that matter.

Consensus specification, section 1: Bitcoin is a distributed consensus system that maintains a shared ledger of transactions without requiring trusted intermediaries. The system achieves consensus through proof-of-work and enforces economic rules through cryptographic validation