Drivechains

The construction begins with an output on the main chain that holds the coins backing the sidechain. To withdraw, a user submits a request on the sidechain, and the request is batched with others into a proposal. Miners then signal their approval of the proposal over a period of blocks, and if enough of them approve, the withdrawal is executed on the main chain.

The signalling is the mechanism that replaces the federation. Rather than a fixed group signing withdrawals, a supermajority of miners votes on each batch, and the vote is what authorises the release of coins. The design's argument is that miners have an incentive to protect the value of the chain they earn from, so they will not approve a theft that would damage it.

The proposal also includes a mechanism for miners to reject a withdrawal they consider invalid, which is intended to give them a way to block a theft without having to approve everything. The details of the voting thresholds and the rejection path are set out in the proposal itself rather than summarised here.

The objection to drivechains is that the incentive argument is not a guarantee. Miners are assumed to act in their long-term interest, but the design does not enforce that they do, and a coalition that decided a theft was profitable could approve one. The federation model has the same weakness with a smaller and more identifiable group, so the question is whether the change is an improvement or simply a different arrangement of the same trust.

There is a further concern about the effect on the main chain. If miners can authorise the release of coins on a sidechain, they have a power that does not exist today, and the concern is that this power could be extended or abused in ways the proposal does not anticipate. The argument is not that a specific attack is known but that the change adds a capability whose consequences are hard to bound.

The proposal's response is that the alternative — a federation — is worse, because it concentrates trust in a small group that is easier to coerce and harder to replace. That is a fair argument, and it is an argument about relative trust rather than about eliminating it. A reader evaluating the proposal should weigh it as such, and should note that the proposal's own discussion acknowledges the assumption rather than hiding it.

What is specified is the drivechain proposal itself: the main-chain escrow output, the sidechain withdrawal request, the batching of requests into a proposal, the miner signalling thresholds and the rejection path. The specification is complete enough to implement, and reference implementations and test vectors have been produced in the proposal process.

What is implemented is limited to that proposal work. No drivechain consensus change is active on the Bitcoin network, none is part of Bitcoin Core's consensus rules, and no node enforces the signalling rules. A withdrawal authorised by the proposed mechanism could not be executed on the main chain today.

What is not deployed is therefore everything that depends on the change: live drivechains, their pegs, and any sidechain that would rely on miner signalling rather than a federation to release coins. The proposal remains a proposal, and the page presents it as such rather than implying a timeline. A reader should treat every capability described here as proposed, not available.