Forward Blocks proposal reframed Bitcoin scaling as a soft-fork problem

Mark Friedenbach presented “Forward Blocks” at the Scaling Bitcoin “Kaizen” workshop in Tokyo on October 6, 2018, proposing a way to increase Bitcoin’s on-chain settlement capacity through a soft fork rather than a conventional hard fork. The official program placed the 30-minute presentation at 11:50 a.m. Japan Standard Time at Keio University, and the dated slide deck identifies Friedenbach as the author with no organizational affiliation.

The development was a research proposal, not a Bitcoin network upgrade. No consensus rule changed on October 6, 2018, and the presentation did not establish adoption by miners, node operators, wallet developers or Bitcoin Core maintainers. Its significance was narrower but still substantial: it challenged the assumption that a large capacity increase, or a change to proof of work, necessarily required old nodes to be left on incompatible rules.

What the proposal attempted

Forward Blocks combined several mechanisms that were usually discussed separately. An upgraded “forward” chain would order transactions under new rules, while a compatibility chain would later reproduce that ordering so unupgraded nodes could eventually observe the same transactions. The design paired extension-block-like capacity with a deliberately constrained use of Bitcoin’s timestamp and difficulty-adjustment behavior. It also introduced a second proof-of-work function, which the paper said could be a salted form of merged mining rather than a forced retirement of existing SHA-256 hardware.

The paper’s recommended starting configuration split the forward chain into 28 shards with separate unspent-transaction-output sets. Each shard targeted a 15-minute interval. Friedenbach calculated that the initial configuration would process an aggregate 4.45 million weight units per 10 minutes, 11.25% above Bitcoin’s four-million-weight-unit maximum on October 6, 2018. Those figures were design parameters and author calculations, not measured throughput from Bitcoin’s live network.

Growth was meant to be gradual and demand-responsive. The proposed baseline limit could adjust after each 2,016-block shard period, with the paper calculating a maximum change of about 14.5% per year. Miners could also vary an individual forward block’s maximum weight within a defined band, accepting a corresponding reward trade-off. These details sought to answer a central objection to on-chain scaling: capacity could rise only if validation costs and mining-centralization pressures remained bounded.

Why it mattered in 2018

Bitcoin’s scaling dispute was also a dispute about governance. A hard fork could make previously invalid blocks valid, requiring broad software coordination and risking a persistent chain split. A soft fork tightened the rules seen by upgraded nodes while allowing older software to remain on the same history, although old nodes would not enforce the new rules.

Forward Blocks tried to preserve that compatibility while avoiding the main weakness of ordinary extension blocks: hiding complete transactions from unupgraded nodes. The proposed compatibility chain would eventually replay forward-chain transactions in order. That made the proposal relevant not merely as a block-size idea, but as an attempt to change how Bitcoin could make large protocol transitions without a flag-day upgrade.

The trade-offs were formidable. More throughput still meant more computation, storage and bandwidth for validators. Separate shards complicated wallet and transaction handling. A proof-of-work transition created new incentive and security questions. The paper itself described its maximum capacity as a protocol limit, not a reasonable near-term operating target, and said reaching it under the proposed growth constraints would take roughly half a century of uninterrupted maximum increases.

What was—and was not—established

The verified October 6 record establishes that the proposal was publicly presented, documented and debated. It does not establish production readiness, peer-reviewed security, implementation in Bitcoin Core or community agreement to deploy it. The Scaling Bitcoin organizers described their workshops as inputs to continuing engineering and review, not as decision-making bodies.

A Bitcoin Optech summary published on October 9, 2018 later clarified the mechanism for technical readers: forward blocks would supply extra space, while restricted legacy-block timestamps would accelerate compatibility blocks enough to carry the same transactions. That later explanation supports the interpretation of the October 6 materials, but it does not convert the proposal into an adopted upgrade.