On 2/23/2022 6:28 AM, ZmnSCPxj via bitcoin-dev wrote:
... Drivechains is implementable on a Turing-complete
language.
And we have already rejected Drivechains, for the following reason:
1. Sidechain validators and mainchain miners have a strong incentive to
merge their businesses.
2. Mainchain miners end up validating and commiting to sidechain blocks.
3. Ergo, sidechains on Drivechains become a block size increase.
Is this indeed the reason? Because it is not a good one.
First, (as always) we must ignore BIP 301*. (Since it was invented to cancel point 1. Which it does -- by giving an incentive for side-validators and main-miners to UN-merge their businesses.)
With that out of the way, let's swap "blocksize increase" for "mining via natural gas flaring" :
1. Oil drillers and mainchain miners have a strong incentive** to merge their businesses.
2. Mainchain miners end up drilling for oil.
3. Ergo, sidechains on Drivechains become a requirement, that full nodes mine for oil.
The above logic is flawed, because full nodes can ignore the mining process. Nodes outrank miners.
Merged mining is, in principle, no different from any other source of mining profitability. I believe there is an irrational prejudice against merged mining, because MM takes the form of software. It would be like an NFL referee who refuses to allow their child to play an NFL videogame, on the grounds that the reffing in the game is different from how the parent would ref. But that makes no difference to anything. The only relevant issue is if the child has fun playing the videogame.
(And of course, merged mining long predates drivechain, and miners are MMing now, and have been for years. It was Satoshi who co-invented merged mining, so the modern prejudice against it is all the more mysterious.)
Also:
1. The sidechain-to-mainchain peg degrades the security of sidechain
users from consensus "everyone must agree to the rules" to democracy
"if enough enfranchised voters say so, they can beat you up and steal
your money".
In this write-up, I will...
This is also a mischaracterization.
Drivechain will not work if 51% hashrate is attacking the network. But that is the case for everything, including the Lightning Network***.
So there is no sense in which the security is "degraded". To establish that, one would need arguments about what will probably happen and why. Which is exactly what my original Nov 2015 article contains: truthcoin.info/blog/drivechain/#drivechains-security , as does my Peer Review section : https://www.drivechain.info/peer-review/peer-review-new/
(And, today Largeblocker-types do not have any "everyone must agree to the rules" consensus, at all. Anyone who wants to use a sidechain-feature today, must obtain it via Altcoin or via real-world trust. So the current security is "nothing" and so it is hard to see how that could be "degraded".)
--
I am not sure it is a good use of my time to talk to this list about Drivechain. My Nov 2015 article anticipated all of the relevant misunderstandings. Almost nothing has changed since then.
As far as I am concerned, Drivechain was simply ahead of its time. Eventually, one or more of the following --the problem of Altcoins, the human desire for freedom and creativity, the meta-consensus/upgrade/ossification problem, the problem of persistently low security budget, and/or the expressiveness of Bitcoin smart contracts-- will force Bitcoiners to relearn drivechain-lore and eventually adopt something drivechain-like. At which point I will write to historians to demand credit. That is my plan so far, at least.
--
As to the actual content of your post, it seems pro-Drivechain.
After all, you are saying that Recursive Covenants --> Turing Completeness --> Drivechain. So, which would you rather have? The hacky, bizzaro, covenant-Drivechain, or my pure optimized transparent Bip300-Drivechain? Seems that this is exactly what I predicted: people eventually reinventing Drivechain.
On this topic, in 2015-2016 I wrote a few papers and gave a few recorded talks****, in which I compared the uncontrollable destructive chaos of Turing Completeness, to a "categorical" Turing Completeness where contracts are sorted by category (ie, all of the BitName contracts in the Namecoin-sidechain, all of the oracle contracts in the oracle sidechain, etc). The categorical strategy allows, paradoxically (and perhaps counterintuitively), for more expressive contracts, since you can prevent smart contracts from attacking each other. (They must have a category, so if they aren't Name-contracts they cannot live in the Namecoin-sidechain -- they ultimately must live in an "Evil Sidechain", which the miners have motive and opportunity to simply disable.) If people are now talking about how Turing Completeness can lead to smart contracts attacking each other, then I suppose I was years ahead-of-my-time with that, as well. Incidentally, my conclusion was that this problem is BEST solved by allowing miners to censor contract-categories (aka censor sidechain-categories, aka 'beat people up' as you put it), which is how I invented drivechain in the first place.
*Shrug*,
Paul
*A small table which explains how this works: https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki#notation-and-example
**Doubtless many of you have heard of this new trend: oil drillers encounter unwanted natural gas, in areas where there are no natural gas customers. Instead of waste this gas, they have begun selling it to miners. https://economictimes.indiatimes.com/news/international/business/oil-drillers-and-bitcoin-miners-bond-over-natural-gas/articleshow/82828878.cms .
***As is well known, it is easy for 51% hashrate to double-spend in the LN, by censoring 'justice transactions'. Moreover, miners seem likely to evade retribution if they do this, as they can restrain the scale, timing, victims, circumstances etc of the attack.
****https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
https://www.truthcoin.info/blog/contracts-oracles-sidechains/
https://www.truthcoin.info/blog/drivechain-op-code/
https://www.truthcoin.info/blog/wise-contracts/