Frequently Asked Questions

Updated March 2023

See also Drivechain Q&A by fiatjaf (creator of Nostr).

1. Security

Miners set the withdrawal destination? Won’t they just steal all the L2 coins for themselves?

Yes, Miners set the destination for withdrawals.

The security model is econonmic. Miners “farm” sidechains for their txn fees (and their exchange-rate value-add).

The idea is that greedy miners will not kill the goose that lays the golden eggs.

See the original 2015 post and also this math for concrete numbers.

Withdrawals are very slow, deliberate, rare, and auditable. It is impossible for miners to steal coins, without it being a deliberate concious, comitted effort over 3-6 months. To steal coins in this way, would be to conciously pull the plug on the Drivechain idea.

Isn’t that a bad model?

Not really.

We currently have ZERO sidechains. So even a 99.99% unpopularity rate (and a 100% failure rate of unpopular sidechains) would be an improvement over the status quo. At least we’d improve from 0% to 00.01%.

The risk-reward decision is one each user should make. Not you! If you don’t like a particular sidechain, or sidechains in general, then don’t use them! It’s like that slogan: “If you don’t Like Gay Marriage, don’t get one!”.

Users today sell their BTC for goods/services; for fiat; and for Alts. Why deny them the option to move their coins to a sidechain? They are the owner. Not you! Mind your own business!!

What negative impact could sidechains have on the mainchain (ie, Bitcoin Core)?

There are none, actually.

I looked into it in detail, in 2016.

Really?! What about miner incentives?

Drivechain is comparable to RIOT’s use of “power curtailment credits”. It is just a new way for miners to make money.

When I’m asked: “does drivechain affect miner incentives?” I say “no”. I personally lived through the invention of: FPGAs/ASICs, heat-reuse, stranded natgas flaring, curtailment credits, and a whole lot else. Merged mining was invented by Satoshi in 2010, and is already in continuous use. So, to someone like me, getting revenues from merged mining doesn’t even register as a change. It’s just business as usual.

All BIP300 does, is supercharge MM. With sidechains, miners would (hopefully) get huge revenues (and profits) from MM… instead of the pittance they get from MM today.

Are you sure that isn’t bad?

Yes, I’m sure.

Profits are good for miners. And good for us. They increase Bitcoin’s security budget. They increase the network Difficulty. They deter 51% attacks (by making them more expensive).

Mining has seen many “changes” that have increased profits. Merged mining is no different than those changes.

But this is a change that affects the protocol!

BIP300 affects the L1 Bitcoin protocol; the sidechains themselves do not.

The L1 protocol never behaves differently, based on something a sidechain does, ever. It only behaves differently based on what the BIP300 messages do. All BIP300 messages are included in the L1 blockchain – your node has to look at them anyway. Enforcing BIP300, does NOT mean downloading sidechain software, nor seeing sidechain blocks nor sidechain transactions.

Whether the miners download sidechain software, and collect coins over there… that’s their business, not yours. They already face this decision with merged-mined Altcoins. And they make it without any input from you! Mind your own business!

Are you absolutely sure about that? It sounds heretical.

Unfortunately, Blockstream’s paper mistakenly defined “mining centralization” as: “when any miner increases their profits”. (Read Section 4.3 and see for yourself.)

This mistake is the worst thing to happen to Bitcoin in its history. It led to years of irrational prejudice against merged mining. Years of “miner centralization bad” = “any increase in miner profits bad” = “miners collecting more txn fees sometimes, is bad”. Which is unfortunate because the opposite is true. Of course.

BIP300 forces miners to care about something new: maximizing sidechain utility, and sidechain txn fees. This is good for us – one more task that our mining servants perform, for us. And if they don’t perform –if they don’t work as hard as they possibly can, as hard as all their rivals at least– then they are fired.

Miners have to care about new stuff all the time (such as natural gas credits example, two answers ago). This is heathy and normal.

What is the correct definition of “mining centralization”, then?

If you ask me, the correct definition of “mining centralization” is: the cost of starting up a new, viable mining pool. Thus, we can increase decentralization by making it easy to pool hop, and making high-quality open source pool software widely availiable for free.

The centralization you should focus on, is CONOP centralization – the cost of starting up a new full node. CONOP centralization is the “real” form of centralization, and it is unaffected by the arrival of a new BIP300 sidechain. (There is a microscopic, fixed increase in CONOP, due to enforcement of the BIP300 rules, but by the time BIP300 activates, this increase will have been offset 1000x by everyday advances in computer power/cost.)

Your node only enforces the BIP300 rules on L1 messages; your node does not look at any L2 messages.

For block-finding, it is the same as merged mined Namecoin which has existed for years.

For the withdrawals – well, why wouldn’t miners steal from them?

It would end the flow of sidechain txn fees.
It might negatively affect the price of Bitcoin.
The slow, rare nature of the BIP300 withdrawal makes it very easy for everyone to audit a theft. Even laypeople will know, with certainty, who is stealing from who. It’s like shoplifting, but you are on national live television, and can only move in ultra-slow motion. The theft will be noticed, understood, communicated worldwide, and universally condemmed, several months before it can actually “go through”.

More details are in the original 2015 post.

If withdrawals are so slow, won’t users hate that?

No. Only specialists will use the BIP300 withdrawal. It can only pay out to 20,000 L1 destination UTXOs, anyway. So it is capped at 20,000 outputs per 3-6 months.

Everyone else will transact with those specialists. The specialists will be exchanges like Coinbase/Kraken/Sideshift, or they will be private users trustlessly swapping coins with HTLCs.

The specialist charges a fee, but users get to move their coins from L2 back to L1 immediately. The layperson customer never has to wait.

What if a sidechain becomes so successful, that it becomes the dominant chain?

Drivechain is asymmetric. The child sidechain is subordinate to the parent mainchain, always. If the mainchain ceases to exist, then all child sidechains cease to exist as well.

Does Drivechain rely on a UASF to prevent sidechain theft?

No.

I will unpack this answer, in three sections.

(i) The UASF Can Do Anything (It Can Prevent Miner-Theft)

A UASF can block a sidechain-theft… but a different UASF can force a sc-theft to go through!

The UASF is flexible. Here are some possible UASFs:

Every coinbase after block #800,000 must contain the word “Hello”.
Block #888,888 must only contain TxIDs that start with an 8.
Block #1,000,000 must contain an OP RETURN gif of Napoleon Bonaparte dancing.
Starting block #925,000, every TxID that starts with 7, is banned.
Starting block #975,000, every TxID must start with 4, is banned.
The following Bip300 withdrawal TxID, is banned forever: “4h2f…”
The following Bip300 withdrawal TxID, MUST be included in block #950,000: “4h2f…”

You can even do all those, together. (In which case, the Napoleon gif will need to be one whose TxID starts with 4.)

Anyway, you can see that we can force any sc-theft to succeed via UASF, or fail.

Thus, it is wrong to imbue the UASF with an “anti-theft” feature. Inherently, it is neither pro-theft nor anti-theft. It allows users to clarify, VERY loudly, what they want to buy, when they hand over $186,000 USD (at 3/22/2023 prices) to miners in exchange for the newest 6.75 BTC (assuming +0.5 BTC of tx fees). UASFs have no inherent allegance to a consensus rule; nor any inherent hostility.

But, yes, a UASF can block a sc-theft.

(ii) UASF Drama?

But what is the effect on 3rd parties? Is there drama.

To explain this, we must explain the UASF in more detail.

First: what is this UASF?

Sidechain-theft can be blocked, with a UASF of the following form: prevent the upcoming theft-txn from entering the blockchain, ever. If it works, then their sidechain-coins are saved! If it doesn’t work, then the UASFers lose nothing – they’re in the same position they’re in now. That is what the victims will try.

Second, this “withdrawal dispute” UASF has unusual properties:

No code changes are needed. No code needs to be written, nor reviewed nor bike-shedded. No software needs to be downloaded, etc. Miners have already chosen the TxID they will steal with, and everyone knows what it is – thus, the UASFers need only select it, and ban it. It is a simple point-and-click.
While the UASFers are immediately alerted to the problem, their UASF cannot take place until later – until after the theft-txn has accumulated its required 13,150 ACKs. Thus, the actual USAF is planned “today”, but it cannot actually happen until “3-6 months from now”.
There is no need for the UASFers to choose an exact time of their fork. Nor do they need to specify activation, nor signal to each other. The fork event is tied to “the inclusion of the theft-txn” in a L1 block. So, no coordination is needed among UASFers. They can successfully pull the whole thing off, even if they never speak to each other.

Third, let’s imagine that a theft is attempted, users counter with a UASF, and the miners don’t back down. On the day of the theft, the coin splits into two. What happens now?

Well, one coin will have a higher market price than the other.

The miner-thieves hope that their coin is the higher-priced. If so, they will happily mine the more-valuable chain. 100% of the hashrate will mine the more profitable coin, even miners who were personally against the theft or miners who prefer to own the UASF coin. This is a crucial point, see “if a miner would rather hold B2X, they could earn it four times faster by mining B1X and trading it for B2X”, for the explanation in the context of SegWit2x. Thus, the UASFers will be on a stalled chain, with 0% hashrate. They may see a few altrustically mined blocks, but it will not be enough. The UASFers have lost, and they stay on a stalled chain, individually, until each admits defeat. They must “unblock” the TxID of the theft txn, and allow it.

In this case, all neutral people will be on the longest-hashrate chain, the whole time – they will not even notice that anything has happened. So they are unaffected by the failed UASF.

But what if the UASF succeeds? If the UASF-coin has the higher price, miners will be forced to mine it (by the exact same logic as before.) The network will remain one blockchain (or re-fuse into one blockchain). It will be a chain where the theft-txn did get all 13,150+ ACKs, and it could be included in a block, but it never is (eventually the 26,000 BIP300 window expires, and the theft-txn with it). The UASFers win; the miners fail to steal.

But what of the neutral parties? If the price differential is large, then the network will never actually split (this happened with SegWit2x – “fork futures” warned us in advance which chain would die, and it was never born). If the price-differential is tiny (ie, market is mostly indifferent – this is pretty unlikely), then both chains may live for a short time. The networks have identical protocol rules, so every txn broadcast during this time will be included in both chains. (In other words, there would be full transaction replay; unlike in the BCH case where there was the exact opposte: mandatory full replay protection.) Any malicious double-spenders, can be defeated by via recipient asking for txn confirmation on both chains, before considering a payment finalized (it is not possible for a layperson user to “accidentally” double-spend, in this case). Ultimately, one chain wins and the other dies – it is as if they own a DropBox folder that splits into two identical dropbox folders and then collapses back into one.

In the very worst case (and unlikely) scenario, there is a reorg that affects some transactions. This requires the market to be somehow “undecided” up until (and during) the fork, and then to decide to be anti-UASF for a little while, and then change its mind. It is a pretty far-fetched scenario. More likely, fork futures will warn us in advance, which coin will be worth more.

(iii) In Context

Any group of people, can decide to UASF, at any time, for any reason. (Such as the dancing Napoleon gif reason.) Drivechain might create “theft events”, which attract UASF attention, but probably not. And what of all the UASFs that DC prevents? For example, DC (if popular) removes the need for all future soft and hard forks. On net, drama on L1 would plummet due to Drivechain.

Also, reorganizations –while unfortunate– are already an inherent risk of using Bitcoin. Each user can voluntarily mitigate this risk, in the usual way (waiting for more confirmations). Drivechain should only be blamed for any new risks it might introduce – not risks that already exist!

What does DC “Rely” On, if not UASFs?

If you go here, you see that DC relies on:

The m parameter (sidechain-able BTC being worth more, than mono-chain BTC)
The b parameter (the fee-revenues from the sidechains).

Why does drivechain allow miners to deny the creation of a given sidechain? Are you against permissionless innovation? Are you a BitMain shill??

Miners will add a sidechain if it makes money to do so.

Also, Miners will remove a sidechain, if it makes money to do so.

Miners earn more, by removing a sidechain?! How could that happen??

If one sidechain prevents a 2nd from reaching its full potential, then the 1st sidechain is a troublemaker. It should be gotten rid of, the same way that security guards keep out thieves.

See my “Smart Contract Ecology” presentation (or answer below for more details.

This is actually why a sidechain-system is superior to one single general purpose blockchain (as in Ethereum).

In the security model you mention “sounding the alarm”, where users and miners warn other users and miners. Isn’t this centralization / collusion?

One reddit user writes: “Drivechains have 1008-block cycles ostensibly to protect against theft, so that someone can ‘raise the alarm’ and tell miners to downvote a particular theft withdrawal, but that sounds too much like centralized collusion to me.”

While this is collaboration, it is not centralization. Drivechain is designed so that everyone can independently respond to the alarm by doing the right thing. They do not need to coordinate with a leader, or a large miner or other users, or anything else. They simply know what to do, because, by design, it is very easy for them to learn what to do. In this case the design is much better than, the March 2013 consensus failure emergency. A drivechain theft would be exactly like that event (in which everything worked out just fine), except that it would be much better, because everyone would: [1] have plenty of warning, and time to respond (two months or so), and [2] would already know what to do (either downvote everything, or manually upvote the winner, both will work).

Why can there be only 256 sidechains? Won’t we run out?? There are 600,000 Altcoins on coinmarketcap!

256 is the right number. The people who disagree, fail to grasp the following facts:

We can have sidechains of sidechains, so the true number is unlimited.
By limiting the number to 256, we can id a sidechain using just one byte. Any more would require two bytes, and allow us to count to 65,000+ which is overkill.
The “600,000 Altcoins on coinmarketcap” represent only ~40 novel ideas. The other 599,960 coins are just a carbon-copy of one of the 40, with a different name. The name is the only new thing.
Many of those ideas are novel consensus mechanisms.
- They replace proof-of-work with something else. (This is near-certain to fail.)
- They try to solve a problem that has already been solved by Merged-mining. So they add no value to a merged-mined Bitcoin sidechain.
If necessary, we could just add a second BIP300, “BIP300b”, that adds 256 more slots.

2. Comparisons

How does this proposal compare to the proposal in the Oct 2014 paper “Enabling Blockchain Innovations with Pegged Sidechains”?

Only in Appendix B is there a concrete suggestion. It was never implemented in the real world, and in the paper it is immediately qualified with the sentence “A detailed analysis of this problem and its possible solutions is out of scope for this document”.

Nonetheless we can compare.

In Drivechain it is impossible to conduct a surprise attack, impossible to harass the community writ large with many withdrawal attempts (ie a “mosquito strategy”), and very easy for users to understand that the attack is happening, long before it actually happens. Also, each attempt is very simple, one question of ‘Endorse’/’Reject’ – quite comparable to the the March 2013 anti-consensus event.

A slow transparent process means that it is impossible for miners to attack the chain and claim that they didn’t know that they were doing so – with transparency, everyone knows, observers as well as the miners themselves. So it is a clearer demonstration of malice.

Blockstream’s skiplist proof is “in the tens of kilobytes range”. DC requires first an M3 message, and next many M4 messages. Roughly 1 marginal byte per sidechain per block. Over 13,150 blocks, this is 13.150 KB per sidechain of course. So Drivechain’s size is slightly smaller.

What is the difference between drivechain and extension blocks?

Both approaches attempt to solve the problem of extensibility – “extending” the capabilities of Bitcoin beyond those which currently exist.

This extensibility problem is a difficult one to solve, because of Bitcoin’s unique emphasis on “consensus” – that all users agree on the state of the blockchain. Since all users must agree, and agreement isn’t free, there is also an implicit agreement on a “minimum required effort” or “minimum tolerable workload”. Bitcoin plays by certain rules, and if those rules are to be meaningful they must be enforced as-written.

So we have a situation where [1] the rules (including “required effort” rules) must be enforced, but simultaneously one where [2] users might like to experiment with new rules. In short, we want the benefits of a “hard fork” (and of permissionless innovation) without paying the costs (which are a loss of consensus, or non-enforcement of important rules).

The trick is to try and solve both problems at once. A ‘hard fork’ solves only problem [2], and ‘doing nothing’ solves only problem [1]. Extension blocks make some progress toward solving problem [2], at the expense of tremendous sacrifice on [1]. This is because users of the non-extended original chain, are subject to a potential barrage of messages. These messages can be sent at any time, by anyone (including an attacker), and could take on any properties (large in size, difficult to process, slow to validate)…most important of all, invalid messages can be sent for free. In this scenario, the cost of maintaining consensus over “Original” is in great danger (according to some) of rising to “Original” + “Extension”, anyway. This means that the extension block is effectively a hard fork, and we have failed to solve challenge [1].

Instead, Drivechain condenses the from-extension-to-original messages into infrequent, easy to validate, unambiguous, chain-scale messages. It essentially flips the consensus threat on its head by arguing that the sidechain should do all of the consensus labor, and it should then present a tiny, minimal easy-to-verify proof of that labor to the mainchain at infrequent intervals. (In the sense of being “difficult to generate but easy to verify”, it resembles proof-of-work itself.) This allows us to solve problem [2] without compromising on [1].

This is why Adam Back in particular emphasizes the “slow return” feature of Drivechain, whenever possible (recall that Dr. Back was a major innovator and promoter of extension blocks in early 2014).

What about Zmn..’s Sidechain-Headers-on-Mainchain (SHoM) ?

Again, to repeat the answer for extension blocks (above), the distinction between hard and soft forks isn’t the point.

The point is, instead, the burden placed on existing users. While an extension block does allow ‘oldtype nodes’ to ignore the extension data, it does this at a cost of no longer being able to fully-validate the block. It is a ‘backdoor hardfork’, of a kind, because users need to upgrade.

Imagine five different scenarios:

Hard Fork to a 2.2 MB
Evil fork to a 2.2 MB
Extension Block adding +1.2 MB
Segwit ExtBlock adding +1.2 MB
Drivechain adding +1.2 MB

Keep in mind that, in order to use Bitcoin as money, every user must check every txn for double-spending. Therefore, if we narrowly assess each of these scenarios in terms of “the burden they place on existing users”, we get the following:

A hard fork is bad, because old users must upgrade, and track 1.2 more data.
An evil fork is bad, because old users must upgrade, and track 1.2 more data.
An extension blocks soft fork is bad, because while old users don’t need to upgrade yet, they might need to have done so at any time.
A SegWit extension block soft fork was bad, for the exact same reasons (immediately above).
A drivechain is good, because it does not force you to upgrade; and if you need to upgrade you will be given plenty of warning, and ultimately even if none of the upgraded / non-upgraded people agree there are no consensus failures on the mainchain.

In my view, SHoM is too similar to an extension block. And it therefore lacks drivechain’s most important features.

What about NiPoPoW by A. Kiayias and D. Zindros ?

I tweeted my thoughts on this article. I am happy that the authors worked on this, but I do not think that I can use it for anything.

What about ZK Validity Rollups?

Rollups pack a list of txns into a smaller amount of L1 space. Thus, they are a perfectly legitimate L2.

They have several drawbacks when compared to drivechain.

First: the benefits of rollups are much lower.

Rollup’s increase in onboarding capacity is capped. See an example of capped-ness here:

The onchain transactions needed to open and settle (and
occasionally rebalance) self-custodial Lightning channels
take up a measureable amount of limited bitcoin block space.
This block space footprint results in a hard upper limit
on the number of self-custodial users who can be onboarded
to Lightning in a given period of time. The additional
transaction capacity enabled by validity rollups could
be used to support more Lightning transactions ...
For 2-P2WPKH-input-1-P2WSH-output-2-P2WPKH-output
dual-funded channels, rollups can create room for up to
3.8x more Lightning channel open transactions.

In contrast, in Drivechain the onboarding growth factor is not limited to 3.8 – instead it is unlimited.

If rollups use an account model (vs utxo), their growth factor may be 10x or 100x more (ie, it may be 38x or 380x). But I have yet to see anyone describe, design, or code this.

Furthermore, rollups do not have as much flexibility as sidechains. (Sidechains have unlimited flexibility – everything in a rollup must in principle be writeable to L1, whereas sidechains are the reverse: everything experienced on the sidechain must be in principle ignorable on L1.)

Second, rollups require a big change to L1: L1 must validate zk-snarks. Bip300 is just an integer that counts from 1 to 13,150, which is something that anyone can understand and audit. Zk-stuff is rightly called “spooky moon math” and most experts are (or were) confounded by it (see here and here). The average person has zero chance of ever grasping the difference between a zk-proof system that is pretending to work (vs one that is working genuinely). You might say: so much the worse, for the average person! Rightly so, but “most L1 node runners” also have zero chance of understanding or auditing these systems. Nor does the economic center of gravity of the Bitcoin system. In contrast, things like hash functions and signatures are simple operations that a user can perform for themselves, many times – thus they can learn the basics and “audit” their computer.

Third, rollups do nothing to solve the “data availability problem”. Drivechain does not solve it either… but Drivechain is at least designed with this DA failure mode in mind. To marginally address DA, Drivechain rewards L1 miners with txn fees (via merged mining); and rewards L2 users (via useful services). Rollups are often presented as though they are impervious to failure. But really: DA is where the rubber meets the road, and rollups do nothing about this big problem.

Fourth, despite the above limitations, the main “advantage” that rollups have over DC, is very very small. The advantage is: the supposed benefit that “51% miners cannot steal from” rollups. Firstly, this comparison is weak, because in DC an actual theft requires 6 months of open, easily-demonstrated misbehavior. So DC theft is enormously impractical – like robbing Fort Knox in slow motion. Secondly, in the rollup case, if evil miners are determined to steal (from rollups), then they can also spend six months doing something comparable: refuse to allow the L1 zk-snark message into the L1 blockchain. This holds the rollup funds hostage – miners can refuse to allow rollup-withdrawals, unless desperate users sell their coins to the miners for pennies on the dollar. If miners start this on Jan 1, likely that many users will have given up by July 1. So the main advantage rollups have over DC is not significant.

Fifth, the “advantage” in point four is (yet again) just a misunderstanding of the DC “miners can steal” problem. “Miners can steal” is not a bug, it is a feature (for DC). See the long presentation on “Sidechain Privatization”, if you want to be one of the very few people who understand why. Not that it matters much in this case, since rollups are also not flexible or general purpose enough to cause too much inter-chain damage.

3. Usefulness

How can we ensure that Great Altcoins are transformed into Sidechains?

If Altcoins are useful, they should have fee-paying users. Therefore, miners should want to claim these fees.

Why would anyone make a sidechain, when instead they could make a great ICO Scam and/or Altcoin?

It doesn’t matter.

If they make an Altcoin, and the Altcoin is useful, then we will copy that Altcoin into a sidechain (as we have already done for zCash and Ethereum). This is easy to do.

If they don’t make the Altcoin; or they do make it and it isn’t useful, then we won’t copy it.

People buy Altcoins to make money! Not for their features, Paul! How could you make such a silly mistake?

Darknet markets have switch from BTC only, to XMR only. Since no one holds the coin (the buyer, the seller, nor the DNM), this cannot be related to the coin’s exchange rate. It can only be related to the XMR superior privacy feature.

But sure, if people only want to buy/flip/pump crypto-assets, then they can continue to do that, on the BitAssets sidechain.

Two sociopaths can’t pump-and-dump each other. It requires at least one guillible victim. In Alt-land the guillible victim is always told a story that involves the coin’s distinctive features. With sidechains, we can copy these features. We get the utility, AND we disable the “story”. So, sidechains help in either case.

With respect to a “LargeBlock sidechain” specifically …

…why should I need to xfer my UTXOs from main-to-side at all? That’s inconvenient – with a hard fork, they just show up there.

Sidechains are “opt in”. So if you want to use the new feature, you must “opt in” to it.

…will the “SmallBlock mainchain” even have enough tx-bandwidth for all of our [LargeBlocker] coins to escape?

A wealthy Bitcoiner could deposit many coins into the sidechain in a single transaction.

He can then onboard new users over there, without consuming any marginal L1 bytes.

So sidechains can grow in all the ways that Altcoins can grow.

4. Abilities and Limitations

Can we have a sidechain that uses Proof of Stake?

Yes, we could. The concept of the 1st sidechain BIP, hashrate escrows is flexible enough to copy any blockchain – public or private, proof-of-stake, proof-of-space, proof-of-steak, etc. Even weirdo stuff like Corda.

However, Drivechain ships with a specialized, customized feature called ‘blind merged mining’ (BMM), which makes consensus on the sidechain free. As in, free in both the economic and engineering sense (see below). If a chain uses BMM, it freely inherits all of Bitcoin’s proof of work security. In fact, the sidechain gets all of Bitcoin’s security, even if its transaction fees [or its other miner-revenue-sources] fall to zero.

For those reasons, BMM is the recommended consensus algorithm for Bitcoin drivechains.

( …perhaps we should invent some sexy-sounding “proof-of-X” name for BMM, like “Proof of Merge”? And bundle it with ridiculous-sounding (but technically true) claims like “even more efficient than PoS”. )

How is Blind Merged Mining doing achieving consensus for free (above)?

The original specification is here, and the BIP text is here. I would first look at the table in the beginning of the BIP text.

BMM only allows one side:block to be found per main:block. This side:block hash must be inserted into “critical real estate” in the L1 coinbase. L1 miners “auction off” this real estate, to the highest bidder.

Here is a more detailed explanation.

Can Bitcoin L1 switch to Blind Merged Mining?

No. The BMM trick requires a “regular” PoW blockchain to exist. It can’t work all by itself.

All the money earned by all sidechains will ultimately go to mainchain Bitcoin miners, so, economically, it really is as if miners were actually mining several chains at once. Except, in this case they only need to run a Bitcoin node.

If Simon keeps a cut, then who would ever use BMM? Why allow Simon to keep a cut, when Mary can run a full node and collect 100%

The full node might be expensive to run.

For example, a node costs $20 to run (amortized over 10 minute periods) and fees are $100 (also amortized over 10 minutes), then Simon can BMM and pay $81 to choose the next sidechain block. Mary won’t run her own node.

So, Simon’s cut actually helps Mary make even more money than she would have made otherwise. It isn’t a disadvantage at all.

The equilibrium value of the cut is near zero. Every sidechain user is already running a side:node. So it is a sunk cost. Paying $81 to earn $100, is always profitable. It doesn’t matter that the node cost $20. Paying $82 to win $100, is more profitable than losing the bid (where you pay nothing to earn nothing). So the equilibrium “cut” will always be near-zero.

If the fullnode costs are too low to justify BMM…well that simply indicates that there’s no problem and no one needs to care.

Obviously, in an asymmetric system, a mainchain can have two or more sidechains. But can you do the reverse, and have a sidechain of two different mainchains at once?

Yes. But this is a convoluted and terrible idea.

For example, you could have a sidechain of Bitcoin that was also a sidechain of Ethereum. The user would need to run all three full nodes, in order to validate the sidechain. The sidechain might need to be blind merged-mined on only one chain, or perhaps it could alternate chains or have an extremely strange chain-integration rule. The security/stability of the sidechain would probably be equal to that of the most insecure/unstable mainchain.

Is there anything that drivechains can’t copy?

The underlying consensus of L1 (PoW vs PoS), and the community.

For example, Monero has a larger anonymity set, as of this writing. And Ethereum has more txn fees and users.

Must each sidechain have a 10 minute blocktime?

You could change it. But you shouldn’t. Trust me, you don’t need to.

It is possible to have “instant” sidechain txns, using special “setup” transactions that have already been confirmed. The lightning network is one example of this; a second example is Double Spend Forfeits et al.

Is the 13,150 ACK parameter hardcoded? Why not let each sidechain specify it?

Yes.

To prevent a “race to the bottom”.
To promote solidarity among all sidechains, in the event of a theft.

5. Other

What kind of sidechain projects can we expect?

Please navigate to the sidechain projects section.

For more info, watch “Drivechain - Overview and Misconceptions”.