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/
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
