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:
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.
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.
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.
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:
I have some remarks about this complaint before I respond:
Now, my responses:
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).
