The security model is comparable to Bitcoin’s. Bitcoin protects a given txn by bundling it with all of the other recent txns (such that the miners cannot revert a txn without attacking the entire chain). Drivechain protects only a subset of the total Bitcoin txns, but it compensates for this by bundling these txns over a much longer period of time.

Security is higher when:

  • The sidechain in question is popular with users.
  • There are many popular sidechains.

A more important point is this: the risk-reward decision is one which should be up to each individual user. If you don’t like a particular sidechain, or sidechains in general, then you don’t have to use them!

But don’t try to decide on behalf of other people! If each individual user is free to sell his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny users the opportunity to move their money between two sidechains.

There are none, actually.

Users are free to ignore any sidechain software they don’t like. And, thanks to something called “blind merged mining”, even miners are free to ignore sidechain software they don’t like (while still being able to mine these sidechains for transaction fees).

This means that the sidechains are completely firewalled from each other. The mainchain cannot be harmed by the mistakes of its child sidechain. Even the ecological effects are neutralized.

In fact, because Drivechain is asymmetric (in that the child sidechain is subordinate to the parent mainchain), the mainchains cannot be harmed even by the success of their sidechains. Since Bitcoin Core would be the patriarch of this family of sidechains, Core would be the safest chain of them all.

The phrase “rely on” is ambiguous in this case, but the answer is “no”. I will give the answer in three sections.

(i) Live by the UASF, Die by the UASF

The UASF can do anything - which is the problem. A UASF can block a sidechain-theft, but it can also force a sc-theft through. And everything in between: a UASF could guarantee that all sc-withdrawals always fail (whether these be theft-withdrawals or honest-withdrawals); or else a USAF could be done to make all honest withdrawals always succeed as quickly as possible. Or that all thefts always succeed on precisely the 22,222nd block after they are attempted (or any other number between 13,150 and 26,300).

So it is not meaningful to imbue the UASF with an “anti-theft” feature. Instead, the UASF is simply a vehicle through which users clarify, VERY loudly, exactly what it is they want to buy from miners when they hand over 140,000 USD (at 2/18/2018 prices) in exchange for the newest 13.5 BTC (assuming 1 BTC of tx fees). If a UASF fails, then it had no effect. If a UASF succeeds, then by definition it has defeated the miners. So, yes, a UASF can block miner-theft.

(ii) “Preventing” Theft

If miners are determined to theft-attack a sidechain, then a UASF is probably the victim’s best recourse.

This UASF would (when the withdrawal finally goes through, 3 months from now) split the chain. At which point the victims would hope that exchanges support [what will be, by definition] a minority hashrate chain. UASF-ers hope that the free market favors their UASF-coins (vs the non-UASF-coins), with a higher price. If those two conditions are met, then users will defeat the miners. The miners will be forced to extend the UASF-chain (ie the non-theft chain), and it will become the longest chain (re-fusing them into one chain).

Thus, the UASF “prevents” the sidechain-theft. But only if the UASF increases the market price. Nodes trump miners, but the market trumps both.

(iii) What does DC “Rely” On

In DC, thefts are deterred by the security model. Sidechain-enabled coins are worth more (to miners and everyone else) than mono-chain coins – this is the “m” parameter. Sidechains give miners additional fee revenues (the “b” parameter). – but only while they are safe to use.

UASFs may provide a secondary deterrent.

Furthermore, the personal shame of the miners, or the potential of new sidechain-inventions, could be further deterrents.

The extent to which the system “relies” on either is hard to know. In the real world, do contracts “rely”, on courts, to be enforced? 99%+ of contracts never see a court. The two parties will work together to enforce the contract on each other. They will only “go to court” as a last resort. So, at first glance the court is superfluous. On the other hand, we would wonder how the absence of a judicial system might affect people’s willingness to fulfill their contractual obligations. Maybe the court is an effective deterrant. Maybe the court isn’t that important and citizens would “rely on” something else (personal reputations, credit scores), in its absence. Hard to say.

Remember that DC actually “relies” on theft to some extent. Some sidechains are bad, and we want miners/investors to get rid of them for us. See this infographic. Remember also: the only way we can detect sc-theft for certain, is by running a sidechain node – but this is exactly what sidechains are uninterested in doing. Sidechains must open the door to theft; if they don’t they aren’t sidechains (see: very first answer in this FAQ).

Despite the previous answer, where I say that drivechain does NOT rely on a UASF, I will answer this question. I believe the answer to this one is also a no, because UASFs can in fact be made to be socially scalable.

First, let us imagine that mining conditions have reached a point of extreme hostility, such that each withdrawal must be manually escorted across the finish line by a new UASF. (In this way, the withdrawals would “rely on” UASFs.)

Is this technique “socially scalable”?

Greg Sanders suggests on Twitter that the answer is “no”. Surely, if this technique worked at scale, mining itself would be unnecessary. Bitcoin would just let the blockchain grow arbitrarily, and leave “the free market” to sort it all out somehow (presumably, with thousands of UASFs per day).

But I think that the answer is actually “yes”.

The key difference lies in the user’s alternatives. If were trying to create a blockchain from scratch (“Proof-of-UASF-Coin”), then your users have no alternatives, and are held hostage to PoUSAF-Coin’s success. In this sense I agree with Greg Sanders that the UASF is a non-solution.

However, once we already have a few different blockchains set up, the user has an option to simply wait. So, the default policy of everyone could be to prevent all withdrawals, unless the evidence of their honesty is overwhelming. (It is a little like how, if you actually go to court, you need to have all of your documents very organized – you cannot waste the judge’s time.) The social scalability can be increased arbitrarily, at a cost of making all of the withdrawals more likely to fail (ie, time out) or else by simply making them all take much longer. In other words, instead of checking in on a sidechain once every 3 months, you could check in on each sidechain once every year, or once every two years.

And, as luck would have it, “slowing everything down” yet another difference between our case and the ‘from scratch’ case. There, slow means slow, and degraded performance for everyone. But in our multi-network case, only the side-to-main PegOut withdrawals are delayed…users can immediately use Atomic Swaps to sell their side:BTC for main:BTC. Speculators will compete to give them the best prices, and, through the magic of the market, every single sidechain user will become precisely as patient as the most patient person in the network.

So the social scalability can be reclaimed, without the entire system failing. Instead, one aspect of it simply becomes a little bit more expensive.

It is true that a sidechain-induced UASF can cause a mainchain reorganization.

This requires five things to happen, in a row:

  1. Attackers are not deterred from attacking, and they initiate a theft.
  2. Some users decide that they will UASF to prevent the theft.
  3. Miners carry a theft 13,150 places (ie, the attack succeeds).
  4. Most miners guess that the non-UASF side will win… (ie, there is no immediate surrender, and the chain splits).
  5. …but this guess is wrong. (The UASF ultimately wins and the chains refuse.)

I have some remarks about this complaint before I respond:

  • This is a complaint that the UASF succeeds in blocking SC-theft. It prefers that user’s funds be stolen. Instead of worrying that [1] the UASF wouldn’t work, or [2] that users would not be motivated UASFing, this complaint is the opposite: that people put in the effort and that they succeed.
  • Miners always have to “choose” the side of the fork that the investors choose. Even if the miners prefer Coin B to Coin A, if the market price of Coin A is highest, then miners can maximize their number of Coin B by mining the A network and selling those A_coins immediately for B_coins. Indeed, this realization is exactly what killed off the misguided SegWit2x fork.
  • This complaint requires the miners to pick the “wrong” side (ie the side opposed by the investors), despite the fact that miners want to always pick the “right” side. Miners have some (small) opportunity to discover which side is right ahead of time, so this complaint requires the miners to act against their self interest. Each block of the non-UASF chain is mined at full strength, but will ultimately be worthless.
  • This “complaint” is not just that DC causes the mainchain to reorg, but also that it causes the mainchain’s coins to become more valuable.
    • This is because the reorganization will only take place, if investors decide that the non-UASF side will not win (and therefore that the coins on that side are worth less). However, at this point in the timeline, the non-UASF side is the “real” side – it is the heaviest (most-work) mainchain. So this reorg can only be one that significantly increases the value of everyone’s mainchain BTC hodlings.
    • By a utilitarian criterion, the reorganization is “the right thing to do”. This is because the market price is an objective measurement (of subjective factors). The non-UASF-price is the price of “theft-laden” token, and the UASF-price is the price of a “reorg-laden” token. If the UASF price is higher, the damage of the reorg [to mainchain Bitcoin value] is smaller than the damage of the theft [to same]. So this is a complaint that the network will automatically do the right thing.
    • In other words, the complaint here is that Bitcoin investors love Drivechain so much that they are willing to reorg for it.

Now, my responses:

  1. I’m not sure that this complaint is logically consistent. It requires two things: first, that the investors and some users challenge the miners and defeat them, but also second, that the miners not to be deterred from attacking in the first place. In other words, in the list above, items 4 and 5 seem to contradict items 1 and 3.
  2. Miners lose big by betting against the wrong side of the fork. They have an incentive to defect to the winning side as quickly as possible.
  3. This complaint is not really a conflict between miners and users. Instead, it is a conflict between investors (who prefer reorgs over SC-theft) and merchants (who prefer SC-theft over reorgs). The investors are strictly more important (in part because they contain opinions about what is best for merchants, but the reverse is not necessarily true).
  4. The problem mostly solves itself, because of txn replay. We might tighten the UASF further, so as to neutralize the impact of the reorg. We force the UASF chain to be aware of its rival [the non-UASF chain], and we force it to “replay” as many of those txns as possible. In particular, the UASF chain would watch the non-UASF for “buried” blocks (those with 6 or more confirmations), and it would then be required to replay as many of those txns as possible. Of course, we do not want to do this perfectly, because we want speculators to take sides and establish different prices for the two tokens. So instead, we might simply decide to do nothing, and let txn replay naturally confer double-spend-protection to many people. Perhaps, the only thing we’d do, is disable RBF for buried non-UASF txns.
  5. Independent of Drivechain, we should already have protection built into wallet software that warns people of a rival blockchain.

The most important response of all, is to point out how out-of-context this complaint is. Complaints such as these scratch the bottom of the barrel as far as relevancy. Meanwhile, Bitcoin has serious competition in the form of “dumb but popular” Altcoins (think Qwerty keybord vs. Esperanto the “best” language; VHS vs BetaMax etc), messy hard fork campaigns, and fundamental [not-resolvable] disagreements over how much it should cost to run a Bitcoin node. These are serious problems that Drivechain has a shot at solving. What is presented in the complaint above is as follows: that there might occasionally, with overwhelming advance warning, be a small mainchain reorg, supported by the economic majority, to prevent sidechain theft, if numerous people act against their own self interest all at once. Contrast that with how much “mainchain contagion” we would have if Ethereum simply displaced Bitcoin as the Internet’s money.

Unlike other projects, drivechain explicitly aims to allow miners to censor certain types of smart contract. I call this feature “categorical control”. Simple-minded people misinterpret this design goal as an affront to permissionless innovation – “After all”, they think, “if miners can censor a type of smart contract, how can it be a permissionless system?”.

I have been repeating myself on this topic for years (both in person and via YouTube lecture), and replied on bitcoin-dev about it, and written about it on my blog (and in the BIP documentation) on several occasions. It is certainly one of the most frequently-asked-questions, especially among Bitcoin-experts who should know better.

The short answer is that Bitcoin users might disagree with the intended behavior of the sidechain. It is assumed that miners must meet the needs of users as best they can (and that, at worst, there can be confusion among miners over what it is that user want). The group “Bitcoin users” can be defined either as [1] the subset of users known as “the economic majority”, or as [2] “the entire population of sincere users”; it doesn’t matter.

In other words, I am saying that all of the users, taken together, would all prefer it to be the case that certain types of smart contracts become impossible. I have provide concrete examples of such cases here). And it is not so strange – any population of humans will all prefer that the crime of theft be universally impossible. And, (closer to home) the population of Bitcoin users prefers that it be impossible for miners to create Bitcoin blocks that contain double-spent txns (in which case we would not need nodes, as all necessary validation could be client-side and off-chain).

Therefore, the idea of “allowing miners to censor sidechains by category” is not a rejection of permissionless innovation, even though it may seem that way. The activities in question are already censored by the laws of economics. Users will never be able to use a “parasite contract”, in practice, because the host will either already be dead or [more likely] will never be built. So, the ability of miners to “censor” these parasites is a moot point. However, with a little ‘categorical control’ the tables are turned – the parasites can be deleted as a category, and it is therefore the parasites which we will probably never see. Instead, we will get all the good stuff, and it will all still be permissionless.

In general, I think that the people who have trouble understanding these explanations are falling victim to a cryptography vs game theory disparity that I have elsewhere described. At our current level of e-cash technology, the “cryptographer nirvana” of ‘complete independence from the miners’ is unattainable. Instead, users, developers, investors, and miners all interact with each other and are dependent on each other. By understanding this interdependence we can try to solve problems, but by rejecting interdependence we really just give up on solving them.

This is why the strongest cryptographers often have no solutions to Bitcoin’s largest problems: scaling, outreach, competition from Altcoins / rival systems, dissatisfied collaborators, and too few developers / dev turnover. Instead, these people tinker with obscure mathematical toy problems, which are very complex and impressive…but have less actual significance.

( Incidentally, it is also why I believe that general-purpose smart contracting systems, like Ethereum and Rootstock, are misguided. These “general-purpose” systems actually can’t do as much as a subset of individually selected smart contracts – ironically, their generality limits their usefulness. )

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.”

In this case, the word ‘collusion’ is misused. In one sense, the word is neutral, meaning “working together”. One could say that there is already a lot of Bitcoin collusion today, because all Bitcoin users and miners are coordinating in order to run mutually-compatible versions of Bitcoin. Everyone is colluding, but everyone wants to get the right answer. So in this case collusion is a good/neutral thing.

In the second more negative sense, ‘collusion’ implies some secrecy and nefariousness (to gain an edge on a different group, one made up of earnest and independent people). But that sense does not apply here. Sounding the alarm is 100% transparent. In fact, it is an alarm! Very loud!

And this “collusion” [of sounding the alarm] is only possible if the bad guys have themselves just “colluded”. The baddies have to collude first (over which WT^ to upvote). In response, the defenders have to do exactly as much colluding work. But it is easier for the defenders because they can move second – the do not need to lift a finger until after the attackers have invested the effort of attacking.

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).