Blind Merge Mining (BMM)

What Is Blind Merge Mining?

Blind merge mining (BMM) is a mechanism that allows proof-of-work Bitcoin miners to secure sidechains by committing sidechain block hashes into Bitcoin blocks, all without running the sidechain's node software or validating its transactions. The miner is "blind" to the sidechain's contents: they simply accept a fee in exchange for including a 32-byte hash in their coinbase transaction.

The concept was formalized by Paul Sztorc and CryptAxe in BIP-301 (first drafted in 2019) as one half of the drivechain proposal. While BIP-300 handles the two-way peg that moves BTC between the mainchain and sidechains, BIP-301 handles how sidechain blocks get mined. The two BIPs are largely independent of each other and can be used separately.

BMM was designed to solve a key problem with traditional merge mining: the requirement that miners run full node software for every chain they want to secure. This requirement increases operational costs and can push smaller mining pools out of participation, contributing to mining centralization.

How It Works

BMM involves two actors and two on-chain messages. By convention, BIP-301 refers to the sidechain block producer as "Simon" and the Bitcoin miner as "Mary."

The BMM Request

The sidechain block producer (Simon) runs a sidechain full node, assembles a sidechain block from pending sidechain transactions, and computes its hash (called h*). Simon then broadcasts a BMM Request transaction on the Bitcoin mainchain containing an OP_RETURN output with the following data:

OP_RETURN
  0x00bf00          # 3-byte message header
  [sidechain_num]   # 1 byte: which sidechain (0-255)
  [h*]              # 32 bytes: sidechain block hash
  [prevMainBlock]   # 32 bytes: previous Bitcoin block hash

The prevMainBlock field is critical: it ties the request to a specific position in the Bitcoin blockchain, ensuring that stale requests cannot be collected later. A BMM Request is only valid for the block immediately following the referenced mainchain block.

The transaction fee attached to this BMM Request is what incentivizes the Bitcoin miner. Simon effectively pays the miner in BTC to commit the sidechain block hash. This fee comes from the sidechain transaction fees that Simon collected when assembling the sidechain block.

The BMM Accept

The Bitcoin miner (Mary) sees BMM Request transactions in the mempool. If she wants to collect the fee, she includes a BMM Accept message in her coinbase transaction's OP_RETURN output:

Coinbase OP_RETURN
  0xD1617368        # 4-byte message header
  [sidechain_num]   # 1 byte: which sidechain
  [h*]              # 32 bytes: must match Simon's proposed hash

Consensus rules enforce that the miner cannot collect the BMM Request payment unless the corresponding BMM Accept with the matching h* appears in the same block's coinbase. This prevents miners from taking the fee without actually committing the sidechain block.

End-to-End Flow

1. Simon runs a sidechain full node and assembles a new sidechain block from pending transactions
2. Simon computes the sidechain block hash (h*) and broadcasts a BMM Request transaction on Bitcoin's mainchain
3. Mary (the miner) sees the BMM Request in the mempool and includes a matching BMM Accept in her block template's coinbase
4. Mary mines the Bitcoin block, collecting the BMM Request fee along with normal transaction fees and the block subsidy
5. The sidechain network sees the commitment in the Bitcoin block and accepts Simon's sidechain block as valid

At no point does Mary download, run, or validate any sidechain software. She simply includes a hash and collects a fee, exactly like processing any other Bitcoin transaction.

BMM vs. Traditional Merge Mining

Traditional merge mining, pioneered by Namecoin in 2011 and later adopted by RSK (Rootstock), requires miners to run full node software for both the parent chain (Bitcoin) and the child chain (the sidechain). This approach has several drawbacks that BMM specifically addresses.

The key insight is that BMM separates the roles of block construction and block commitment. In traditional merge mining, the miner does both. In BMM, the sidechain operator constructs blocks while the Bitcoin miner simply commits the hash. This separation means miners can secure an unlimited number of sidechains without any increase in operational complexity.

The Drivechain Context

BMM (BIP-301) is one half of the drivechain proposal. The other half, BIP-300 ("Hashrate Escrows"), defines a two-way peg mechanism that allows BTC to move between the mainchain and sidechains. BIP-300 uses a slow withdrawal process where miners vote over approximately three to six months to approve sidechain-to-mainchain withdrawals.

Together, BIP-300 and BIP-301 would enable fully functional Bitcoin sidechains where users can deposit BTC (via BIP-300's peg-in), transact on the sidechain (with blocks secured via BIP-301's BMM), and withdraw BTC back to the mainchain (via BIP-300's peg-out). However, the two BIPs are independent: BMM could theoretically be used without the hashrate escrow peg, and vice versa.

Historical Development

The idea evolved through several iterations. In June 2017, Chris Stewart proposed OP_BRIBEVERIFY on the bitcoin-dev mailing list, an earlier version of the BMM mechanism that would have redefined the NOP4 opcode. This approach was later superseded by the current BIP-301 design, which uses OP_RETURN messages instead of a new opcode, avoiding the need for a soft fork of Bitcoin's script system.

Alternative Approaches

Covenant-Based BMM (Spacechains)

Ruben Somsen proposed an alternative form of blind merge mining called Spacechains that uses covenant opcodes (such as SIGHASH_ANYPREVOUT from BIP-118 or OP_CTV from BIP-119) instead of the BIP-301 mechanism. Spacechains pre-compute a long set of transactions that maintain a UTXO representing the sidechain state, creating a one-way peg sidechain without requiring a BMM-specific consensus change.

CUSF Deployment

LayerTwo Labs, the company founded by Paul Sztorc to develop drivechain software, has explored deploying BIP-301 via CUSF (Client-side User Softfork Filtering): an out-of-process enforcer client that connects to a standard Bitcoin Core node via RPC and ZMQ. This approach would not require changes to Bitcoin Core itself but would need majority hashrate adoption of the enforcer software to be effective.

Use Cases

BMM enables a range of sidechain designs that would inherit Bitcoin's proof-of-work security without burdening miners with additional software:

• Experimental consensus rules: sidechains could test new script opcodes, block sizes, or transaction formats without risking the Bitcoin mainchain
• Scalability layers: high-throughput sidechains could process large volumes of transactions, with only the block hash committed to Bitcoin for security anchoring
• Privacy chains: sidechains with confidential transactions or zero-knowledge proofs could operate alongside Bitcoin, inheriting its hashrate security
• Application-specific chains: sidechains optimized for specific use cases (prediction markets, identity systems, tokenization) could run their own consensus rules while being anchored to Bitcoin

Why It Matters

The question of how to scale Bitcoin and add new functionality without compromising its base layer security is central to the Bitcoin layer-2 landscape. BMM offers one answer: let sidechains experiment freely while inheriting Bitcoin's hashrate security, all without forcing miners to take on new operational burdens.

For the broader Bitcoin ecosystem, BMM represents one of several approaches to enabling sidechain security. Layer-2 protocols like the Lightning Network, Spark, and others each take different approaches to scaling and extending Bitcoin. Understanding BMM helps contextualize these design choices, particularly around the tradeoffs between miner involvement, validation costs, and security guarantees.

Risks and Considerations

Miner Censorship

Because miners do not validate sidechain state, they have no inherent incentive to protect any particular sidechain. A miner or mining pool controlling a majority of hashrate could refuse to include BMM Accept messages for a specific sidechain, effectively censoring it. Since the miner's only stake is the BMM fee (not sidechain tokens or reputation), the cost of censorship is limited to forgone fees.

Invalid Block Commitment

A malicious sidechain block producer could submit an invalid sidechain block hash to a miner, and the miner would commit it because they cannot distinguish valid from invalid sidechain data. Sidechain full nodes would reject the invalid block, but the invalid commitment would still occupy space in the Bitcoin block. This means sidechain security depends entirely on sidechain full nodes, not on Bitcoin miners.

Activation Controversy

BIP-301 (along with BIP-300) has been a subject of significant debate in the Bitcoin developer community. Critics have raised concerns about the security implications of hashrate escrows, the complexity of the proposal, and the potential for sidechains to create new attack surfaces. As of 2026, both BIPs remain in draft status with no clear path to activation on Bitcoin mainnet. LayerTwo Labs maintains testnet implementations, but no production sidechain currently uses BMM.

Security Model Differences

In traditional merge mining, miners validate both chains, providing a direct security guarantee. With BMM, miners provide only a commitment service. The sidechain's security model shifts from "miners enforce the rules" to "sidechain full nodes enforce the rules, and miners provide ordering." This is a fundamentally different security assumption that may be weaker for sidechains with small full-node networks.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.