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. 🧡
https://t.co/9abFpGlb65
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.
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. 🧡
https://t.co/9abFpGlb65
@reardencode Those nine rows are CONSENSUS_SPEC.md, which is derived from the Orange Paper indirectly. connect_block already follows Core on eight of them. The prose is out of date but the implementation is not.
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.
https://t.co/9abFpGlb65
@nonhelix Appreciate the question, worth a look. Yes, the retry timer is randomized per transaction, so there's no fixed window an observer can use to work back to the origin. Most transactions fluff out before the timer even fires anyway.
This is why I’m so excited to be contributing to BLVM.
When I advocated for Bitcoin Knots and BIP-110, it was never about picking sides in a developer war. It was about protecting the very principles that made Bitcoin revolutionary in the first place.
The freedom to choose which rules we enforce. The ability to independently verify them. And the right to disagree without having to trust a handful of people to decide Bitcoin’s future for everyone else.
But those debates made something increasingly clear to me. We can’t keep defending decentralization in theory while accepting dependencies in practice.
That’s what makes BLVM so important. An independent node implementation, built around explicitly defined, verifiable consensus rules. Not another coin, not another attempt to control Bitcoin, but another way to independently enforce the rules.
I don’t want Bitcoin’s future to depend on whether the right people happen to be maintaining the right software. I want it to remain resilient even when we disagree, when developers leave, when institutions apply pressure, and when the next generation inevitably challenges the decisions we make today.
Because Bitcoin’s greatest achievement was never just creating money without central banks. It was proving that we could build systems that don’t require us to trust anyone with absolute authority.
Now we need to make sure the infrastructure lives up to that promise.
The answer to centralization isn’t finding better people to trust. It’s making that trust unnecessary.
That’s a future worth building, and I’m proud to be part of it.
Good point, and worth being clear about. Dandelion++ protects one thing, the link between you and the transaction on the network. When you send a payment, it travels through a few random peers before it's broadcast, so someone watching can't easily tell which IP address it came from.
It doesn't hide the payment itself. Amounts, addresses, and the balances on those addresses are public on the blockchain, same as always. It also isn't a replacement for Tor or a VPN if you want to hide your IP from your internet provider. It hides who sent a payment from network watchers, not the payment.
At @LuganoPlanB this weekend telling people about the part of Bitcoin nobody wants to look at. One codebase serves as the spec and as the only implementation that matters, and that concentration is a risk for everyone, including the people who maintain it. @BtcCommons has a formal specification, the Orange Paper, which I wrote, and a separate from-scratch Rust node verified against more than 900,000 blocks with differential testing and fuzzing against Bitcoin Core. The coordination model sits on top of that. If you're here and want to talk through the spec or the model, find me. The Orange Paper and docs are at https://t.co/pLvOED6dCx. #LuganoPlanB
Bitcoin Core has a 76% attrition rate among contributors who cleared the bar for sustained, meaningful work. Across all 7,827 people who have contributed, 90.7% have gone a full year without activity.
Some of the best engineers this protocol ever had wrote code Bitcoin still runs on, then got filtered out by grant politics, stalled reviews, and a merge process where three people control roughly 81% of merges. Plenty of them ended up building on altcoins because that was the only place left to ship.
You shouldn't have to leave Bitcoin to build. Bitcoin Commons is a Bitcoin node implementation on the same chain with the same consensus rules, so everything you contribute here is Bitcoin.
The rejects, the nerds, and the people who just want to help have always been the beating heart of Bitcoin. If you had a PR die without a real review or walked away because the door stayed shut, Bitcoin Commons wants your work. Come build with us.
Source: @DecodeBitcoin@BtcCommons https://t.co/pLvOED6dCx
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. 🧡
https://t.co/9abFpGlb65
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.
Bitcoin's consensus rules have never been written down outside of code. The only authoritative answer to whether a block is valid has been whatever Bitcoin Core does.
So every independent node has had to shadow Core instead of building against a shared reference, and the ones that drifted became chain-split risks.
The Orange Paper is a formal mathematical specification of Bitcoin's consensus rules. Signature validation, UTXO accounting, script execution, and block structure are defined precisely enough for any mathematician, engineer, or court to read and check.
Bitcoin Commons (@BtcCommons) has spent the past 12 months building a from-scratch Rust node against it. Z3 checks consensus paths against the spec on merge, and differential replay compares the node to Core across 900,000+ mainnet blocks.
The spec belongs to everyone. Any implementation can verify itself against it, Core included, and each one that does makes Bitcoin harder to capture through a single codebase.
https://t.co/pLvOED6dCx
AI is changing how Bitcoin software gets built.
Bitcoin Commons (@BTCCommons) and Plebly (@JoinPlebly) are leaning into that rather than pretending it is not happening.
The risk with AI-generated code is not obvious errors. It is subtle behavioral changes that pass code review but introduce vulnerabilities or alter consensus rules in ways no one catches until it is too late. Standard review is not equipped for that.
So we built BTCDecoded Intelligence, a research and review tool trained specifically on Bitcoin's protocol history, governance record, and codebase. It gives us automated review tuned to the actual failure modes of Bitcoin software rather than software in general.
https://t.co/oeqTp0VGXh
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.