@ZmnSCPxj
> we have already rejected Drivechains

I also think this is kind of dubious. I don't remember consensus being to "reject" drivechains, as much as consensus was that it wasn't a priority and there wasn't a lot of interest in doing on it from many people (I'm sure Paul could comment further on that).

> sidechains on Drivechains become a block size increase.

While this would be true for those who opt into a particular drivechain, I think its important to note that it would *not* be identical to a main-chain block size increase in a very important way: normal bitcoin miners and nodes nodes that don't care about drivechains would not see a blocksize increase. 

But even in the hypothetical scenario where *all* mainchain miners expand their business to sidechains, it still does not negatively affect normal bitcoin nodes that don't care about drivechains. The important things about a "normal" blocksize increase are:

A. It increases the machine resources necessary for IBD, transaction relay, and validation
B. It probably increases the growth rate of the UTXO set, increasing memory necessary to store that.
C. It increases the cost of storing the blockchain on non-pruned nodes
D. It increases the average propagation time of new blocks, which increases miner centralization pressure. 

The existence of drivechains with every miner opted into (some of) them would only negatively impact item D. Normal bitcoin nodes wouldn't need to use any extra resources if they don't care about drivechains. And miners would only have additional centralization pressure proportional to what drivechains they're opted into. The reason for that is that if a miner is opted into drivechain X, and propagation of transaction data for drivechain X is significantly slower than the normal bitcoin network, a miner may not have the latest drivechain X block to merge mine on top of. However that miner can still mine bitcoin with no additional latency, and so that centralization pressure is minimal unless a significant fraction of the miner's revenue comes from drivechains with slow data propagation. Beyond that, by my calculations, miner centralization is quite far from being significantly affected by blocksize increases. So unless drivechains become the dominant use case of the bitcoin blockchain, this really isn't something that I expect to cause any substantial miner centralization or other blocksize related problems.

ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you arguing that it would be unwise to opt into a drivechain? Those are very different arguments. If drivechains compromised things for normal bitcoin nodes that ignore drivechains, then I agree that would be serious reason to reject drivechains outright and reject things that allow it to happen. However, if all you're saying is that people can shoot themselves in the foot with drivechains, then avoiding drivechains should not be a significant design consideration for bitcoin but rather for those who might consider spending their time working on drivechains. 

On Thu, Feb 24, 2022 at 6:03 AM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good morning aj,

> > Logically, if the construct is general enough to form Drivechains, and
> > we rejected Drivechains, we should also reject the general construct.
>
> Not providing X because it can only be used for E, may generalise to not
> providing Y which can also only be used for E, but it doesn't necessarily
> generalise to not providing Z which can be used for both G and E.

Does this not work only if the original objection to merging in BIP-300 was of the form:

* X implements E.
* Z implements G and E.
* Therefore, we should not merge in X and instead should merge in the more general construct Z.

?

Where:

* E = Drivechains
* X = BIP-300
* Z = some general computation facility
* G = some feature.

But my understanding is that most of the NACKs on the BIP-300 were of the form:

* X implements E.
* E is bad.
* Therefore, we should not merge in X.

If the above statement "E is bad" holds, then:

* Z implements G and E.
* Therefore, we should not merge in Z.

Where Z = something that implements recursive covenants.

I think we really need someone who NACKed BIP-300 to speak up.
If my understanding is correct and that the original objection was "Drivechains are bad for reasons R[0], R[1]...", then:

* You can have either of these two positions:
  * R[0], R[1] ... are specious arguments and Drivechains are not bad, therefore we can merge in a feature that enables Recursive Covenants -> Turing-Completeness -> Drivechains.
    * Even if you NACKed before, you *are* allowed to change your mind and move to this position.
  * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore we should **NOT** merge in a feature that implements Recursive Covenants -> Turing-Completeness -> Drivechains.

You cannot have it both ways.
Admittedly, there may be some set of restrictions that prevent Turing-Completeness from implementing Drivechains, but you have to demonstrate a proof of that set of restrictions existing.

> I think it's pretty reasonable to say:
>
> a) adding dedicated consensus features for drivechains is a bad idea
> in the absence of widespread consensus that drivechains are likely
> to work as designed and be a benefit to bitcoin overall
>
> b) if you want to risk your own funds by leaving your coins on an
> exchange or using lightning or eltoo or tumbling/coinjoin or payment
> pools or drivechains or being #reckless in some other way, and aren't
> asking for consensus changes, that's your business

*Shrug* I do not really see the distinction here --- in a world with Drivechains, you are free to not put your coins in a Drivechain-backed sidechain, too.

(Admittedly, Drivechains does get into a Mutually Assured Destruction argument, so that may not hold.
But if Drivechains going into a MAD argument is an objection, then I do not see why covenant-based Drivechains would also not get into the same MAD argument --- and if you want to avoid the MADness, you cannot support recursive covenants, either.
Remember, 51% attackers can always censor the blockchain, regardless of whether you put the Drivechain commitments into the coinbase, or in an ostensibly-paid-by-somebody-else transaction.)


Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev