The Drivechain Mechanism Was Already Patented
On vote-counting, blinded commitments, and the difference between inventing something and giving it a different name.
I. A Question of Mechanism
There is a habit, common to people who write protocols and rarer among people who must implement them, of believing that a thing becomes new the moment one gives it a new name. Call a hashrate escrow a “drivechain” and a paired transaction a “blind merge mine,” and you may persuade an audience that you have introduced a novelty into the world. You will not have done so. You will have introduced a vocabulary. The mechanism, which is what actually does the work, will be whatever it was before you spoke about it.
The drivechain proposal — set out in Paul Sztorc’s essay Drivechain: The Simple Two Way Peg, formalised in BIP-300 (Hashrate Escrows) in August 2017, and extended in BIP-301 (Blind Merged Mining) in July 2019 — has been argued about for ten years. Peter Todd was paid by LayerTwo Labs to write a critique of it in 2023, in which he concluded, with the air of someone who has been asked to inspect a bridge designed by people who do not believe in gravity, that the design replaces “the careful incentive design we see in other Bitcoin protocols — and Bitcoin itself — with blind trust in miners.” The debate since then has treated drivechains as a novel proposal whose merits or defects must be weighed on its own terms.
It is not a novel proposal. The mechanism it specifies — distribute identity tokens to a fixed voter set, count their on-chain signals over a window, release pre-locked funds when the count crosses a threshold — was filed as a patent application by nChain on 23 February 2016, eighteen months before BIP-300 was drafted. The patent was granted on 31 May 2022 as US 11,347,838 B2. Its title is unfortunate: Blockchain implemented counting system and method for use in secure voting and distribution. Nothing in the title would draw the attention of a Bitcoin engineer rummaging through prior art under search terms like “hashrate escrow” or “merge mining.” That is part of the reason the connection has gone unnoticed. It does not, however, change what the patent describes.
I want to do something here that the drivechain debate has not done. I want to ignore the names. The names are an obstacle. I want to walk through what BIP-300 and BIP-301 actually do, in operational terms, and then walk through what the patent actually describes, in the same operational terms, and let the reader judge whether the two are the same machine wearing different costumes.
II. What BIP-300 Actually Does
The proposal is a soft fork. It introduces six new consensus messages — M1 through M6 — which travel inside coinbase OP_RETURN outputs, two cached data structures (D1, the sidechain registry, with a hard cap of 256 slots; and D2, the withdrawal-bundle list), and one new opcode, OP_DRIVECHAIN, redefining OP_NOP5. The funds belonging to a sidechain sit in a single mainchain UTXO called the CTIP, gated by OP_DRIVECHAIN, which evaluates to true automatically. There is no signature on the gate. The gate is, in cryptographic terms, anyone-can-spend; in BIP-300 terms, it is governed entirely by the consensus rules wrapped around it.
What concerns us is the withdrawal procedure. Suppose a user wishes to take BTC out of a sidechain. The sidechain aggregates many such requests into a single composite mainchain transaction, called a “bundle,” whose outputs pay each withdrawing user from the CTIP. Because deposits keep flowing in and changing what the CTIP UTXO actually looks like, the bundle’s literal transaction ID is a moving target. BIP-300 solves this in a particular way. It hashes the bundle with the first input and first output zeroed out, calls the result the “blinded TxID,” and treats that 32-byte value as the canonical commitment. Miners will not vote on the bundle. They will vote on the hash.
The first miner to propose the hash includes it in their coinbase as an M3 message. From that block forward, every subsequent block’s miner can write an M4 vector indicating which bundle, in each sidechain, they wish to upvote. Each block can move a bundle’s running ACK counter by exactly one — up, down, or unchanged — and the counter starts at one. The window is fixed at 26,300 blocks, roughly six months. If the counter reaches 13,150 within that window, the bundle “succeeds”: the actual M6 transaction whose blinded hash matches the counter’s target may now be included on-chain, and the CTIP funds are released to the bundle’s outputs. If the window closes first, the bundle expires from D2 and the funds remain locked. The sidechain header must commit to the same bundle hash that miners are voting on, or else honest miners are expected to refuse to ACK; this is the only place where consensus on the sidechain side and consensus on the mainchain side are mechanically tied.
That is BIP-300. Strip the names and the apparatus is plain. There is a fixed voter set (whoever produces the next 26,300 blocks). There is a vote (an entry in coinbase metadata). There is a tally (the per-bundle ACK counter in D2, updated each block). There is a threshold (13,150). There is a window (26,300 blocks). When the tally crosses the threshold inside the window, a previously-locked sum of Bitcoin is released to a destination encoded by the proposal. When the window closes without the threshold crossing, nothing happens.
III. What BIP-301 Actually Does
BIP-301 is a separate piece of machinery addressing a related question: who actually mines the sidechain blocks, and how do they get paid? The answer Sztorc proposes is “blind merge mining.” A sidechain user — Simon — assembles a sidechain block, computes its Merkle root h, and broadcasts a “BMM Request” transaction containing h, the sidechain ID, and a binding to the previous main:block. A Bitcoin miner — Mary — accepts by including the same h* in her coinbase OP_RETURN as a “BMM Accept,” paired in the same main:block to Simon’s payment. The validity rule is that they must match. Mary collects Simon’s fee. Simon’s sidechain block is endorsed by Bitcoin’s hashpower without Mary having to validate or even read the sidechain.
BIP-301 is a paired-commitment escrow with one secret value, h*, committed in two transactions in the same main:block, with mutual validity gated by the match. It is the simplest thing you could build out of two parties who want to commit to the same off-chain object without revealing it on-chain. Simon commits to a Merkle root that summarises an entire sidechain block. The mainchain learns that root and nothing else. The mainchain’s role is reduced to a single function: anchoring the commitment so that it cannot be silently changed.
The word “blind” in “blind merge mining” is doing a specific thing in this design. It is not the cryptographic blindness of a Chaum signature. It is operational blindness: Mary does not see the sidechain block. She only sees its 32-byte fingerprint, and she sees Simon’s payment. This is the same trick that elevators and stock exchanges and notary services have used since clerks first realised that endorsing a thing is not the same as understanding it. The interesting feature, mechanically, is that the entire bridge between mainchain and sidechain is a single shared value committed in two paired transactions — a structure that, if you have read a paper on cryptographic commitment schemes in the last forty years, you will recognise instantly.
IV. The Critique That Defines the Stakes
Todd’s 2023 analysis is worth reading not because his conclusions are decisive but because his diagnosis of the central problem is exact. BIP-300 has no fraud proofs. The 2014 Blockstream pegged-sidechains paper at least nominally allowed for fraud proofs that could cancel a malicious withdrawal during a contest period; BIP-300 simply removes them. There is no recourse if miners vote to steal. BIP-300 and BIP-301 do not interact: there is no mechanism to pay miners for ACK votes, so even if blind merge mining keeps Bitcoin miners from running sidechain nodes for block production, the withdrawal vote still requires them to either run those nodes themselves or trust someone who does. And the architectural choice of giving miners discretion over fund movements turns miners into custodians, with all the consequences that follow from that.
Todd’s central technical point is the one that matters here. In ordinary Bitcoin, a UTXO is gated by a digital signature. No amount of hashpower can forge a signature, which is why even a 51% attack cannot take arbitrary coins. BIP-300 changes that calculus. A 51% miner coalition can take BIP-300-locked coins simply by voting to do so. The lockbox has no cryptographic gate. It has a gate made of miner ACKs accumulated over a window. This is the architectural choice that defines BIP-300, and whatever one thinks of the wisdom of it, it is the mechanism Sztorc proposed: a fixed voter set, iterated voting in coinbase fields, threshold-triggered payment from a pre-locked address, no bonds, no slashing, no cryptographic signature on the withdrawal itself.
V. What the Patent Actually Describes
US 11,347,838 B2 was filed via PCT in 2017 and claims priority to UK applications dated 23 February 2016. It is granted, assigned to nChain Licensing AG, and lists Craig Steven Wright and Stephane Savanah as inventors. The patent’s title would not bring it to the attention of someone searching for sidechain prior art. The mechanism it claims is the following.
A finite set of tokens is created on the Bitcoin blockchain. Each token consists of a Bitcoin public key and private key pair, with a small amount of Bitcoin loaded into the address — one satoshi, in the worked example, representing one vote. The amount is incidental. The role of the loaded BTC is to make the token a valid spendable UTXO. The list of token addresses is published before the vote begins. The mapping from voter identity to specific token is destroyed; the set of authorised tokens is public and finite, and within that set the tokens are anonymous to outsiders.
Voting consists of spending a token-bearing UTXO into a transaction whose output indicates the voter’s choice. A “Yes” vote pays to a designated yes-address. A “No” vote pays to a designated no-address. An abstention does not spend at all. The spend is the vote. The spend is observable to every full node on the network the moment it is mined into a block.
An off-chain “Manager” — the patent also calls it a “bot” or an “oracle,” the words being interchangeable in the specification — runs a loop in parallel with the blockchain. Each iteration of the loop monitors the chain for new spends of token addresses, increments an integer running tally, writes the iteration record back to the blockchain as a new transaction whose metadata stores both the tally and a hash of the loop’s source code, and removes the spent address from the active list. The loop continues iterating until the list is empty, which is to say until every voter has voted or the window has closed.
Now, the worked example, which I want to give in the patent’s own register because the cadence matters: “If the amount of unique ‘Yes’ votes received reaches 57, the agreed amount of Bitcoins will be paid to Jason’s account.”
Read it twice. A finite voter set is enfranchised by holding tokens. They cast votes by performing on-chain actions visible to any observer. A counting agent maintains a tally. When the tally crosses a fixed threshold, a previously-arranged sum of Bitcoin is paid to a previously-specified address. If the threshold is never crossed, the payment never happens. The audit trail is provided by the published source-code hash and the on-chain trail of iteration records, so that any third party can re-run the count.
That is the mechanism BIP-300 describes for sidechain withdrawals, expressed in the slightly different vocabulary of generic vote-counting. It would be a peculiar coincidence if it were a coincidence.
VI. Mechanism for Mechanism
Take Wright and Savanah’s worked example and rewrite it in BIP-300 vocabulary. The voters become the miners. The tokens become coinbase pubkey/privkey pairs — a miner’s right to write into the next block’s coinbase is precisely conferred by their control of a key pair into which the block reward will be paid. The patent does not require tokens to be fungible or to have economic value beyond what is needed to cast the vote; claim 1 says, with the deliberate generality of patent prose, that the token must merely be “represented by a blockchain public key and private key pair.” A miner’s coinbase keypair satisfies this. It would be strange to say it does not.
The vote in the patent is an on-chain action performed by a token-holding entity. In BIP-300, the on-chain action is the inclusion of an M4 upvote vector in the block’s coinbase. The act of producing a block is the act of generating an event observable by every node on the network. The patent’s specification says that “the computing resource may monitor the state of the blockchain for a transaction comprising a cryptographic hash of code relating to the loop.” Every BIP-300 full node does precisely that. It monitors for blocks containing M3 and M4 commitments matching the bundle hash, and updates its D2 cache accordingly.
The tally in the patent is an integer maintained by the computing resource and recorded as metadata in transactions on the blockchain. In BIP-300, the tally is the per-bundle ACK count in D2, updated each block based on the M4 vector. The patent’s claim 11 says: “information relating to at least one iteration of the loop is stored in a transaction on the blockchain.” BIP-300 satisfies this. Every block’s M4 message is exactly such a record.
The threshold-triggered payment in the patent is the payment to Jason once 57 yes-votes accumulate. In BIP-300 it is the unlocking of M6 once 13,150 ACKs accumulate. In both cases the payment is from funds that were locked into the mechanism in advance, and the destination is pre-encoded in the proposal that the voters are voting on (Jason’s address; the bundle’s output addresses).
The window in the patent is the period during which the loop runs — until “the list of addresses becomes empty.” In BIP-300 the window is hard-coded at 26,300 blocks. The framing in the patent accommodates this directly: the loop terminates when no more votes can be cast, which is exactly what happens when the bundle expires from D2.
The audit in the patent is the publication of the loop’s source-code hash and storage location, so that any party can re-run the count. In BIP-300 the audit is provided by the on-chain visibility of every M3, M4, and M6 message, plus the open-source consensus rules that any third party can read.
Every operational element of BIP-300’s withdrawal mechanism corresponds to a claim limitation in US 11,347,838’s vote-counting method. There is no element in BIP-300 that has no analog in the patent, and there is no element in the patent’s claim 1 that has no instantiation in BIP-300. The cosmetic differences are real — the patent talks about Jason and yes-votes, the BIP talks about miners and ACK counts — but the cosmetic differences are exactly that.
VII. The Predictable Objection, and Why It Falls Apart
An attentive engineer reading the patent will reach for a particular escape clause. Claim 1 ends with the limitation: “implementing the loop using a script.” The Bitcoin Core BIP-300 implementation is in C++. C++ is not a script. Therefore — runs the argument — BIP-300 does not satisfy this limitation, and the patent does not read on it.
The argument does not survive five minutes of careful reading.
The patent’s specification uses “script” extensively because the inventors had Bitcoin Script in mind for the on-chain side of the system. But claim 1 says “a script,” not “a Bitcoin script.” When the specification turns to the loop running on the computing resource — the off-chain Manager, the bot, the oracle — it is explicit that the loop runs on a parallel computing resource and that this resource may be implemented in any way. Claim 21 of the patent enumerates the possibilities: “code for the loop is hard-coded into or on the computing resource; stored in a private or publicly available file; and/or stored as an entry on a private or public hash table file; and/or a static code block with hard-coded variables or at least one parameter.” That covers C++, Python, Forth, Bitcoin Script, JavaScript, and any other executable code one cares to name.
The architectural insight of the patent is that Bitcoin Script is non-Turing-complete and cannot loop, so the loop must run on a parallel computing resource. The blockchain holds state and provides verifiability; the computing resource runs the loop. A Bitcoin full node executing BIP-300 consensus rules is exactly such a resource, monitoring the blockchain block-by-block, updating its D2 cache against successive M4 messages, and emitting an action — validation of M6 spendability — when the count crosses the threshold.
“Script” in computer science is not a term of art restricted to interpreted scripting languages. It refers to a sequence of executable instructions. Claim construction proceeds from the meaning a person of ordinary skill would give a term in context, and the context here — the patent’s own use of “loop,” “iteration,” “code,” “the manager runs,” “for each iteration” — makes clear that “script” is the executable code that drives the loop, in whatever language it happens to be written. To carve C++ out as non-infringing would require redefining “script” as an implementation choice rather than a category of executable code, and no reasonable claim construction does that. Code is code. The objection collapses.
VIII. Blinded Values, Where the Whole Family Lives
The vote-counting patent does not stand alone. It belongs to a continuous family of nChain filings with priority dates from February 2016 through May 2018, all naming Wright and (variously) Savanah, and all turning on the same underlying primitive: representing on-chain a thing that is not the actual content of the off-chain operation. The patent literature calls these “veiled values” or “blinded values” — both terms are used in nChain’s own filings, the latter recurring in dependent claims that draw on Chaum’s blind-signature work and the broader cryptographic commitment literature.
Wright’s atomic-swap patent, US 11,838,407 B2 (priority 14 May 2018), is the one most often cited in this connection. It describes a two-party atomic swap in which Alice and Bob each generate a secret, hash it, and exchange the hashes — what the patent calls “veiled secret values.” Each party constructs a UTXO whose locking script requires the preimages of both hashes to spend. Either party’s spend reveals both preimages, releasing both UTXOs simultaneously. The mechanism is symmetric, two-secret, cryptographic-gated.
It does not match BIP-300. BIP-300 has no preimages. But the structural primitive — committing a hash on-chain to bind an off-chain operation that will only be revealed conditionally — is exactly what BIP-301 is doing with h. h is a Merkle root: a 32-byte commitment to the contents of a sidechain block, posted to the mainchain in a coinbase OP_RETURN. The actual sidechain block lives off-chain. Only the commitment is on-chain. When the BMM Request and the BMM Accept match, the commitment is bound; when the sidechain block is later revealed in full, observers can verify that what they see corresponds to what was committed.
This is the primitive that runs through the entire 2016–2018 family of nChain filings: a value committed on the mainchain that anchors but does not reveal an off-chain operation, with the anchor’s validity gated by the underlying ledger’s natural double-spend protection. Wright’s tokenisation patent (Canadian application CA 3013180, priority February 2016, same family as the vote-counting patent) describes the same machinery for tokens. The atomic-swap patent describes it for two-party exchange. The vote-counting patent describes it for threshold-triggered fund release. The patent on agent-based Turing-complete transactions (priority February 2016, also Wright and Savanah) describes the parallel computing resource that maintains state about commitments observed on the chain.
BIP-301 is, in the language of the family, a paired-commitment release of an off-chain Merkle-rooted block. There is one commitment value — h* — and two transactions in the same main:block that must agree on it. The ledger’s natural property of “only one transaction containing a given commitment can be canonical per block per sidechain” supplies the gating. This is the same primitive the family teaches, with one specific binding rule (paired Accept and Request in the same main:block) substituted for the various other binding rules the family describes. It is not the atomic-swap variant — that requires two preimages — but it is unmistakably a member of the same family.
IX. The Architectural Family Tree
Step back from the specific patents and look at the design space. There is a natural taxonomy.
The first axis is the trust model. At one end is pure cryptographic gating: a UTXO can only be spent by producing a valid signature, and no amount of hashpower or social pressure can substitute for that signature. Bitcoin proper sits here. At the other end is unbonded vote-gating: a UTXO is released by aggregated signals from a fixed voter set, with no cryptographic gate on the release itself. BIP-300 sits there. In between are designs that use cryptographic gating but distribute the keys: threshold ECDSA over a bonded validator set (the nChain “congress” patents — US 11,348,095 / US 12,003,616 et seq., priority April–December 2017), federated multisig (Liquid), trusted hardware enclaves (the TEE-bound congress variant). What distinguishes these intermediate designs from BIP-300 is that they keep cryptographic gating in place; they only change who holds the keys.
The second axis is what the on-chain commitment represents. A signature commits to a transaction. A hash commits to whatever was hashed — a secret, a transaction with elided fields (BIP-300’s “blinded TxID”), a Merkle root (BIP-301’s h*), a data packet, a state. The cryptographic flexibility comes from being able to choose what to hash. The trust flexibility comes from being able to choose who is allowed to make the commitment carry weight.
The third axis is what gates the release. A digital signature gate is unforgeable by hashpower. A vote-count gate is forgeable by hashpower over a window, given enough of it. A threshold-signature gate is forgeable only by compromising or coercing enough key-holders to cross the threshold. A hash-preimage gate is forgeable only by inverting the hash function (which, modulo a few decades of cryptanalysis, no one expects).
The drivechain proposal sits in a particular corner of this space: unbonded vote-gating, blinded-TxID commitments, no slashing. The atomic-swap patent sits in another corner: two-party preimage-gating, hashed secret commitments, time-locked refund. The vote-counting patent occupies a corner that contains drivechains as a special case: token-holder vote-gating, with the patent agnostic about whether the tokens are held by miners, by named voters, or by anything else satisfying “predetermined entity.”
The “congress” patents and the TEE-bound variants occupy a different corner from drivechains: bonded validator vote-gating, threshold-signature release, slashing. These are competing peg designs to drivechains, and one can read Todd’s critique of BIP-300 as an argument for the congress corner of the design space — for replacing miner ACK counting with bonded-validator threshold signing — without his ever using that vocabulary. The disagreement between drivechain proponents and the rest is, mechanically, a disagreement about which corner to inhabit.
X. Why the Names Were Misleading
The drivechain literature has not, until now, been in serious dialogue with the nChain patent portfolio because of the gap between the two communities’ vocabularies. Sztorc and his collaborators speak the language of Bitcoin protocol design: hashrate escrow, merge mining, soft fork, sidechain, peg-in, peg-out. The nChain filings speak the language of patent practice: token, predetermined entity, computing resource, loop, iteration, veiled secret value, commitment of a data packet. Each community has been searching the other’s literature with the wrong terms.
The vote-counting patent is the cleanest example. A Bitcoin engineer would never search for sidechain prior art under “voting and distribution,” and the patent’s worked example uses Jason and yes-votes rather than miners and ACKs. But once the cosmetic layer is stripped away, the apparatus is the same one BIP-300 specifies. The blinded-TxID trick that BIP-300 uses for keeping a withdrawal hash static while the underlying transaction’s inputs change is a particular case of the broader veiled-value primitive that the same nChain family teaches: commit to a hash on-chain, let the actual content remain mutable in defined ways, bind the commitment by the host chain’s natural single-spend property. BIP-301’s h* trick is another particular case of the same primitive.
None of this would matter — none of the priority dates would have any consequence, none of the family relationships would be more than a curiosity — if the mechanism in the patent were not the mechanism in the BIP. They are. That is the entire point of removing the names and reading the operations.
XI. A Note on What This Does Not Mean
I have no interest in litigating these claims here, and the post is not the place for legal commentary. What I am claiming is technical. I am claiming that the operational mechanism BIP-300 specifies — distribute identity tokens to a fixed voter set, count their on-chain signals over a window, release pre-locked funds when the count crosses a threshold — was disclosed in the nChain prior art patent literature before BIP-300 was drafted. That is a statement about the patent record and the BIP record, both of which are public documents available to anyone who wishes to read them.
I am also claiming that the operational mechanism BIP-301 specifies — commit a 32-byte fingerprint of an off-chain object on the mainchain, paired with a transaction that pays a fee for the inclusion of the commitment — sits in the same family of veiled-value primitives that the nChain patents from 2016 through 2018 teach. The specific BIP-301 binding (paired Accept/Request in the same main:block) is a particular instantiation of the broader primitive. The family includes the atomic-swap patent’s two-preimage variant, the tokenisation patent’s commitment-and-release variant, the vote-counting patent’s tally-and-threshold variant, and others.
I am not claiming that anyone plagiarised anything. The patent priority filings became public eighteen months after their filing dates, by the standard rules of patent disclosure, which would put the nChain February 2016 priority filings in the public record around August 2017 — the same month BIP-300 was drafted. This is too close to be useful evidence either way of who saw what when. What it does suggest is that several people working on Bitcoin protocol design in 2016 and 2017 converged on the same family of primitives, and that the convergence was natural enough that it would have happened with or without anyone reading anyone else’s work. The mechanism is what matters. The convergence is what one would expect when several people work seriously on the same problem.
XII. Coda
The drivechain debate has, for ten years, treated BIP-300 and BIP-301 as if they introduced new primitives into the world. They do not. They specify particular instantiations of well-defined primitives — vote-counting with threshold-triggered release, commitment-of-fingerprint-with-paired-anchor — that have been around in one form or another since the cryptographic literature of the late 1970s and that, in their specifically-Bitcoin-flavoured forms, were filed as patent applications by nChain in 2016 before any drivechain BIP was written.
None of this is, in itself, a verdict on whether drivechains should ship. That question depends on whether unbonded vote-gating with no slashing is a good architectural choice for handling cross-chain peg withdrawals, and whether the mining-centralisation pressures Todd identifies are tolerable in exchange for the design’s simplicity. These are real questions and the people arguing about them are mostly arguing in good faith. What this is a verdict on is the claim that the underlying mechanism is novel. It is not. The underlying mechanism is a member of a patent family that predates the BIPs by eighteen months and that covers the corner of the design space the BIPs occupy.
The reader who has followed the argument this far will perhaps see why the names are an obstacle. Call something a hashrate escrow and you will draw debates about whether hashpower is a good escrow agent, which is a reasonable debate to have but not the only one. Call it a vote-counting mechanism with threshold-triggered release of pre-locked funds, and you will ask whether the voter set is bonded, what their incentive structure is, whether there is a slashing condition, and whether the threshold and window are well-chosen — which are the questions you ought to have been asking all along. The vocabulary of Bitcoin protocol design has, in the drivechain debate, occluded the architectural questions rather than clarified them. The vocabulary of the patent literature, which is at once more bureaucratic and more general, turns out to make the architectural questions visible.
That is, in the end, what the patent record offers anyone willing to read it: not a ruling, but a clearer view. The mechanism is what the mechanism is. Naming it differently changes nothing.
Oh. The mechanisms in the various patents - are cleaner. They started as a R&D project in 2012.