DRA

Bitcoin Changes - Soft Fork History and Theory - TABConf 6

December 15, 2024Original source

On December 15, 2024 at TABConf 6, Paul surveyed Bitcoin soft fork history and theory, then explained how Drivechain, BIP300/301, sidechains, Blind Merged Mining, and Core Untouched Soft Forks can expand Bitcoin without requiring ordinary users to change their nodes.

Highlights

Key Takeaways

Soft Forks as Optional Evolution

Paul reframes soft forks around their original network function: resolving potential chain splits automatically while letting users upgrade on their own schedule. The talk contrasts the familiar idea that soft forks merely tighten rules with the deeper point that they preserve continuity for non-upgraded users. Examples such as Satoshi-era rule changes and check-lock-time-verify show how new features can become safe once miner enforcement is active, while older software continues following the same valid chain. This framing supports Drivechain as a natural extension of Bitcoin's long-standing upgrade model.

Drivechain as Layered Bitcoin Innovation

Paul connects BIP300/301 to a broader sidechain architecture where experimentation can happen in separate layers while Bitcoin Core users keep their existing base-layer experience. LayerTwo Labs' software work includes a Drivechain testnet, privacy-focused sidechains, Ethereum-style execution on Bitcoin through EthSide, BitNames, BitAssets, and high-throughput sidechains. Blind Merged Mining is presented as a key design feature because miners can receive additional revenue without needing to inspect or operate sidechain-specific systems, keeping Bitcoin's base layer focused while expanding what Bitcoin can support.

CUSF Keeps Core Untouched

The Core Untouched Soft Fork proposal separates soft fork enforcement from Bitcoin Core by using an external activator that gives blocks a second pass and calls Bitcoin Core's invalidateblock RPC when a soft fork rule is broken. Paul presents this as a practical path for restoring faster, permissionless soft fork deployment while preserving the same enforcement effect as traditional in-Core validation logic. Because the activator can be independent software, written in any language, it can reduce dependence on the Core merge process and let miners adopt revenue-positive upgrades such as BIP300/301 through clear hash-rate coordination.