Date: Thu, 24 Feb 2022 12:03:32 +0000
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
In-Reply-To: <20220224065305.GB1965@erisian.com.au>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
 <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
 <20220224065305.GB1965@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
	or the absence thereof,
	was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and
	ANYPREVOUT
Precedence: list

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 =3D Drivechains
* X =3D BIP-300
* Z =3D some general computation facility
* G =3D some feature.

But my understanding is that most of the NACKs on the BIP-300 were of the f=
orm:

* 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 =3D 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 "Drivech=
ains 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, ther=
efore 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 w=
e 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-Compl=
eteness 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 Drivec=
hains, you are free to not put your coins in a Drivechain-backed sidechain,=
 too.

(Admittedly, Drivechains does get into a Mutually Assured Destruction argum=
ent, 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 ar=
gument --- and if you want to avoid the MADness, you cannot support recursi=
ve covenants, either.
Remember, 51% attackers can always censor the blockchain, regardless of whe=
ther you put the Drivechain commitments into the coinbase, or in an ostensi=
bly-paid-by-somebody-else transaction.)


Regards,
ZmnSCPxj