Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT



Summary:

In a discussion on bitcoin-dev, the rejection of Drivechains was questioned as it wasn't necessarily a consensus but rather a lack of interest and priority from many individuals. The potential impact of sidechains on Drivechains becoming a block size increase was also discussed, with the main point being that normal Bitcoin miners and nodes that don't care about Drivechains would not see a block size increase. Even in the hypothetical scenario where all mainchain miners expand their business to sidechains, it doesn't negatively affect normal Bitcoin nodes that don't care about Drivechains. The existence of Drivechains with every miner opted into (some of) them would only negatively impact miner centralization pressure. However, this isn't something that's expected to cause any substantial miner centralization or other blocksize related problems unless Drivechains become the dominant use case of the Bitcoin blockchain. ZmnSCPaj was asked if they were arguing against Drivechains for Bitcoin or just cautioning against opting into a Drivechain. The discussion then turned to an objection to merging BIP-300 because of its implementation of Drivechains. ZmnSCPxj argued that those who NACKed BIP-300 did so because they believed Drivechains were bad for Bitcoin, not because of the general construct. In response to objections that adding dedicated consensus features for Drivechains is a bad idea, ZmnSCPxj argued that in a world with Drivechains, one is free to not put their coins in a Drivechain-backed sidechain. The discussion ended with the understanding that there may be a set of restrictions preventing Turing-Completeness from implementing Drivechains, but a proof of such restrictions existing must be demonstrated.


Updated on: 2023-06-15T16:39:26.100541+00:00