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
