Drivechains Allow Sidechain Node Miners – Bitcoin Magazine
This is an opinion piece by Shinobi, a self-taught Bitcoin educator and tech-savvy Bitcoin podcast host.
This time I’m going to break down and discuss how drive chains work; they were originally proposed in 2015. Of all the proposals discussed so far, drive chains are the oldest and the most concrete in terms of specific implementation details and design, documented in BIPs 300 and 301. Paul Sztorc, the creator of the concept, had some main design goals in thoughts, and while this is not exhaustive at all, here are some:
- Isolate each sidechain so that any error or problem will only affect those using it.
- Allow sidechains to be spun up without needing a new fork for each one.
- Enable the transfer of bitcoin in and out of a sidechain with a two-way peg.
- Allow free experimentation in design that he hopes would obviate the need for altcoins.
There are two primary aspects to the entire design, which is why there are two separate BIPs. The first is the pin mechanism (BIP300), which is what allows the two-way pin to work. Sztorc designed something called a hash rate escrow, which in the most basic terms allows miners as an amorphous group to collect the coins of all sidechains. The other is a “blind” pooled mining scheme, where the goal is to allow bitcoin miners to be block producers at a consensus level without being required to validate the sidechain to do so. Both of these pieces together present a two-way pin mechanism and a way for bitcoin miners to take part in mining the sidechains while trying to reduce the centralization risk that it poses.
BIP300 specifies the logic for the proposal of a new sidechain, the activation of a new sidechain, the proposal of an aggregate set of withdrawals, the approval of such a set of withdrawals, the validation logic for actual withdrawal transactions, and the validation for deposit transactions.
Activating a new sidechain during the drivechain proposal is very similar to the process of a soft fork activated through miner signaling. The biggest difference, of course, is that it’s not actually a soft fork – a single fork to activate the consensus rules for the drive chain allows miners to signal at any time that they’re activating a new sidechain within drive chain consensus rules. To propose activation of a new sidechain, a miner must place an OP_RETURN data in its coinbase output that includes a unique identifier for that sidechain, a public key for use in deposit operations, version data, human-readable descriptions, and hashes to the software client. and the GitHub history of it (there’s no consensus enforcement here, just data that humans can refer to).
When a miner proposes to activate a new sidechain and include all the necessary data in his coin base, it becomes a kind of “miner signaling period” regarding whether this new sidechain should be created from the main chain consensus point of view. A miner may use a particular format to include a proposal in their coinbase outputs, and other miners may create a different output following a different format to signal activation. A new sidechain proposal requires that 90% of the blocks in a difficulty period signal activation for a new sidechain creation to be confirmed. This creates the pin mechanism to activate the side chain, but the interaction between side chain and main chain is more nuanced than that.
At this point, anyone can attach coins to the sidechain. To connect to the sidechain, a user simply creates a two-input transaction with their own input and the UTXO corresponding to the sidechain balance with a single output assigning everything to the sidechain. This guarantees that the sidechain only has a single UTXO that contains all the funds locked into it. Withdrawals are handled by mining voting. The main chain has no understanding of who owns what on the side chain, and the main chain will consider any withdrawal approved by miners within the voting mechanism as valid. Because of this, there is a long delay in the withdrawal process. There are two phases to the process of withdrawing from a sidechain: a withdrawal proposal (bundle), and then the withdrawal vote phase. Miners must create an OP_RETURN output in their coinbase transaction with a hash of the proposed withdrawal transaction to propose a withdrawal. This hash, similar to sighash, only flags that commit to part of a transaction rather than the whole thing. It does not commit to the input UTXO which represents funds locked in a drivechain or the output which returns anything not withdrawn to a special sidechain UTXO. This is because any deposits in the drive chain will create a new UTXO, thus invalidating the commitment of the withdrawal transaction when people went to validate it.
From here, the miner’s voting period on the withdrawal proposal begins. After a bundle is proposed, miners can vote on whether or not to approve it. Each block mined allows that miner to increment an approval counter up or down by one or two to refrain from doing anything. There are some specific restrictions in addition to this, because it is possible to have more than one bundle for a single sidechain — if a miner chooses to vote “yes” (increase the counter by one) for a withdrawal bundle for a sidechain must vote “no” (decrement the counter by one) for every other bundle associated with that specific sidechain.
This is to guarantee that there are no “double withdrawals”, where someone has an exit in multiple bundles that will pay them out more bitcoin on the main chain than they owe.
On the other hand, miners are also allowed to vote no for each and every proposed bundle. This is meant to act as some kind of alarm to everyone that a miner validating these withdrawals (making sure they are legitimately owned coins on the sidechain being withdrawn) has noticed something invalid going on. Remember, a key point of this design is that miners don’t need to validate anything on the sidechain, so unless they choose anyway, many miners may vote up bundles they don’t validate. This alarm function is designed for them to be notified that they should verify the packages to ensure that a fraudulent withdrawal does not occur.
Once a packet has reached the required threshold (13,150 blocks, or about 90 days), the transaction actually processing the withdrawal becomes valid and can be confirmed. But what do people do if miners approve a fraudulent withdrawal that steals money from the sidechain? Sztorc’s proposal is to engage in a user-activated soft fork (UASF) to invalidate the invalid connection transaction. This poses a huge risk in terms of main chain consensus. UASF in 2017 was a high risk move that only barely succeeded and Bitcoin was much smaller than it is today. The larger Bitcoin grows, the more difficult such actions will be to coordinate.
If you remember from the space chains article, the design was based on blind merged mining (BMM). Ruben Somsen’s BMM design is actually the second variant of it, the first being Sztorc’s design as posted in BIP301. The BMM specification in drive chains is composed of two messages: a request message and an acceptance message. Both are coordinated respectively through a special transaction type on the main chain and special output in a miner’s coinbase transaction.
The request transaction is constructed by the sidechain block creator. The whole point of BMM is that this person can be someone who is not mining, so the request transaction is there to allow them to pay miners to confirm their proposed sidechain block. The sidechain block proposal constructs a transaction that includes the hash of the sidechain block, the ID assigned to the sidechain when it was created, and the last four bytes of the previous mainchain block header. There are three additional consensus rules that apply to this type of transaction. First, a request transaction is invalid unless there is also a matching accept output in the coinbase transaction of that block. This is to guarantee that miners cannot charge a fee from the request without also accepting and mining the sidechain block. Second, for each sidechain, only one request transaction is allowed to be included in a mainchain block. This is to ensure that only one block from a sidechain can actually be mined per mainchain block. Finally, the last four bytes of the previous main chain block must match. This ensures that a request is only valid to be mined in the next block, and such transactions cannot be mined later and steal money from a sidechain block proposer after someone else’s block has been mined.
The accept output is very simple: message header data and the hash of the sidechain block. If a miner runs a drivechain node themselves, they can simply ignore request transactions and always include their own accept output in the coinbase to mine their own sidechain blocks. Together, these two aspects allow miners to either operate a sidechain node themselves, or another non-miner to do so and pay the miner to mine their blocks. The idea is that if miners don’t run the sidechains themselves and eat the extra validation costs, then someone else can do it for them. If there is competition between non-miners trying to earn fees on the sidechain, they will likely continue to bid up the fee they are willing to pay miners in the request transaction until it represents the majority of the fees they earn, with the non-miner keeping only a small percentage of profits and pays the rest to miners.
It’s the mechanics behind how drive chains work. Next up, federated sidechains, and then, after that, an overview of all the negatives and drawbacks each design might have.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
