17 posts
First release candidate for Bitcoin Core 31.0 introduces cluster mempool, a fundamental rewrite of transaction management logic that improves block template construction, eliminates ancestor/descendant limits, makes RBF incentive-compatible, and enables privacy-focused transaction broadcast via Tor/I2P.
Bitcoin Core PR #34083 introduces vectorized ChaCha20 implementation achieving 2-3x performance gains. This deep-dive explains why ChaCha20 is critical for BIP324 encrypted transport, how SIMD vectorization works, and what this means for node operators running encrypted P2P connections.
Bitcoin Core PR #34075 introduces mempool-based fee estimation to fix years of systematic overpayment. Here's how it works and why it matters for every wallet, exchange, and Lightning node.
A new BIP draft proposes Pay to Schnorr Key Hash (P2SKH), a witness version 2 output type that combines P2WPKH's compact 22-byte scriptPubKey with P2TR's efficient 64-byte Schnorr signatures. The proposal uses key recovery to validate signatures against a 20-byte hash commitment, saving 12 bytes per output compared to P2TR while maintaining identical witness size.
Bitcoin Core pull request #33043 proposes adding support for Codex32, a paper-based wallet backup scheme that lets users create, verify, and split seed backups using only pen, paper, and lookup tables. Unlike BIP39, Codex32 supports hand-computable checksums, Shamir secret sharing, and error correction without requiring electronics.
Bitcoin Core's fee estimator looks backward, not forward. Here's how it builds estimates from confirmed transactions, why it lags during rapid fee changes, and what the upcoming mempool forecaster will fix.
How attackers exploit Bitcoin's mempool protections to censor transactions, why Lightning Network is vulnerable, and the v3 transaction solution now live on mainnet.
Lightning Network developer Rusty Russell has submitted two draft BIPs to restore Bitcoin's pre-2010 scripting capabilities through a new 'varops budget' system. The proposal introduces tapleaf version 0xc2, re-enables disabled opcodes, dramatically increases stack limits, and addresses the original CVE-2010-5137 concerns with a systematic cost framework.
A deep dive into cluster mempool design, how it improves upon ancestor/descendant limits, and why it matters for miners, node operators, and Layer 2 protocols.
Bitcoin Core PR #34692 bumps the default dbcache from 450 MiB to 1 GiB for systems with 4GB+ RAM, targeting v31 release. Explains the performance benefits of increased cache, why it matters for IBD and validation speed, memory requirements, and whether node operators should adjust manually or wait for the upgrade.
Bitcoin Core v31 will double the default database cache from 450 MB to 1 GB on modern systems, cutting sync times by up to 2.5x. The first default change in nine years targets faster initial block download while protecting low-memory setups.
Bitcoin Core merged PR #34219 on March 4, 2026, adding pubkey validation for MuSig2 pubnonce and partial signatures in PSBT deserialization. This improves security for multisig wallet users and hardware wallet integration.
Bitcoin Core v30.0 introduced experimental Stratum V2 support in October 2025. Five months later, adoption remains slow despite the protocol's promise of better decentralization and censorship resistance.
Bitcoin Core 29.3 fixes a critical wallet migration bug that could delete entire directories, plus sighash caching for DoS defense and mining overflow patches
Three low-profile PRs merged in February 2026 strengthen Lightning tooling, transaction privacy, and eclipse attack resistance in Bitcoin Core 31.0.
Bitcoin nodes can now encrypt their connections by default, shielding transaction relay from ISP surveillance — but most users don't even know it exists.
Bitcoin Core v30.0 quietly raised OP_RETURN limits from 83 bytes to 100kB. New data shows 24 million OP_RETURN transactions since the change, with 396 using the expanded limits. Bitcoin's data layer is waking up, and almost nobody noticed.