BIP 301: Blind Merged Mining (Consensus layer)

In plain English: Blind Merged Mining would let Bitcoin miners earn fees from sidechains without running any sidechain software. Sidechain users assemble blocks and bid for a miner to include a commitment to them, giving miners extra revenue while keeping their workload unchanged.

Status

Draft

Type

Specification

Layer

Consensus (soft fork)

Authors

Paul Sztorc, CryptAxe

Assigned

2019-07-23

Last changed

2025-10-08

Topics

Consensus

Source

bip-0301.mediawiki on GitHub · Markdown

Abstract

Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").

Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).

Motivation

"Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin).

However, traditional MM has two drawbacks:

1. Miners must run a full node of the other chain(s). (Thus, they must run "non-Bitcoin" software which may be buggy.)

1. Miners are paid on the other chain, in Alt-currency. (Miners who MM Namecoin, will earn NMC.)

Notation and Example

We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".

Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.

BIP-301 makes this specialization-of-labor trustless on L1. If Mary takes Simon's money, then she must let Simon control the side:block.

Specification

Each candidate for next side:block is defined by its unique side:blockhash "h*". (Even if the entire rest of the L2 block is identical, different Simons will have different side:coinbases and therefore different h*.)

BIP-301 consists of two messages: "BMM Accept" and "BMM Request".

1. "BMM Accept" -- A coinbase output in L1, which contains h*. Mary can only choose one h* to endorse.

1. "BMM Request" -- A transaction where Simon offers to pay Mary, if (and only if) Mary's L1 block contains Simon's h*.

As a miner, Mary controls the main:coinbase, so she may select any h*. Her selection determines which side:block is "found" -- and which associated BMM Request she can collect.

BMM Accept

To "Accept" a BMM proposal (endorsing Simon's side:block, and allowing Mary to accept Simon's money later in the block), Mary places an OP_RETURN output into the main:coinbase as follows:

    1-byte - OP_RETURN (0x6a)
    4-bytes - Message header (0xD1617368)
    1-byte - Sidechain number (0-255)
    32-bytes - h* (obtained from Simon)

Code details here.

If these OP_RETURN outputs are not present, then no Requests were accepted. (And, Mary would get no money from Requests.)

It is possible for Mary and Simon to be the same person. They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.

When Simon and Mary are different people, Simon will need to use BMM Requests.

BMM Request

Simon will use BMM Requests to buy the "right" to find a sidechain block, from Mary.

For each side:block that Simon wants to attempt, he broadcasts a txn containing the following as an OP_RETURN:

    1-byte - OP_RETURN (0x6a)
    3-bytes - Message header (0x00bf00)
    1-byte - Sidechain number (0-255)
    32-bytes  - h* (obtained from L2 node)
    32-bytes  - prevMainBlock (the blockhash of the previous main:block)

h* is chosen by Simon to correspond to the side:block he wants to mine on the alt-chain. nSidechain is the number assigned to the sidechain/alt-chain when it was created.

This txn is invalid if it fails any of the following checks:

1. Each "BMM Request", must match one corresponding "BMM Accept" (previous section).

1. Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must single out one BMM_Request_4 to include in this L1 block.

1. The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.

Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one that pays her the most.

This BIP allows BMM Requests to take place over Lightning. One method is here. (BMM Accepts cannot be over LN, since they reside in main:coinbase txns.)

Backward compatibility

This soft fork can be deployed without modifying Bitcoin Core at all (ie, via CUSF).

Deployment

This BIP deploys when/if >51% hashrate runs the enforcer client.

Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.

Reference Implementation

The enforcer is here.

Also, several example L2s using BIP-301 are here.

Copyright

This BIP is licensed under the BSD 2-clause license.