Date: Sat, 26 Feb 2022 06:43:52 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com>
In-Reply-To: <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
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>
 <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
 <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
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>,
 Anthony Towns <aj@erisian.com.au>
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,

> ZmnSCPaj, are you arguing that drivechains=C2=A0are bad for bitcoin or ar=
e you arguing that it would be unwise to opt into a drivechain? Those are v=
ery different arguments. If drivechains=C2=A0compromised things for normal =
bitcoin nodes that ignore drivechains, then I agree that would be serious=
=C2=A0reason to reject drivechains=C2=A0outright and reject things that all=
ow it to happen. However, if all you're saying is that people can shoot the=
mselves in the foot with drivechains, then avoiding drivechains=C2=A0should=
 not be a significant design consideration for bitcoin but rather for those=
 who might consider spending their time working on drivechains.

Neither.
My argument is simply:

* If Drivechains are bad for whatever reason, we should not add recursive c=
ovenants.
* Otherwise, go ahead and add recursive covenants.

Drivechains are not a scaling solution [FOOTNOTE 1] and I personally am int=
erested only in scaling solutions, adding more non-scaling-useable function=
ality is not of interest to me and I do not really care (but I would *prefe=
r* if people focus on scaling-useable functionality, like `SIGHASH_NOINPUT`=
, `OP_EVICT`, `OP_CTV`, `OP_TLUV` probably without the self-replace capabil=
ity).

I bring this up simply because I remembered those arguments against Drivech=
ains, and as far as I could remember, those were the reasons for not adding=
 Drivechains.
But if there is consensus that those arguments are bogus, then go ahead ---=
 add Drivechains and/or recursive covenants.
I do not intend to utilize them any time soon anyway.

My second position is that in general I am wary of adding Turing-completene=
ss, due precisely to Principle of Least Power.
A concern is that, since it turns out recursive covenants are sufficient to=
 implement Drivechains, recursive covenants may also enable *other* techniq=
ues, currently unknown, which may have negative effects on Bitcoin, or whic=
h would be considered undesirable by a significant section of the userbase.
Of course, I know of no such technique, but given that a technique (Drivech=
ains) which before would have required its own consensus change, turns out =
to be implementable inside recursive covenants, then I wonder if there are =
other things that would have required their own consensus change that are n=
ow *also* implementable purely in recursive covenants.

Of course, that is largely just stop energy, so if there is *now* consensus=
 that Drivechains are not bad, go ahead, add recursive covenants (but pleas=
e can we add `SIGHASH_NOINPUT` and `OP_CTV` first?).

Regards,
ZmnSCPxj

[FOOTNOTE 1] Sidechains are not a scaling solution, or at least, are beaten=
 in raw scaling by Lightning.  Blockchains are inefficient (THAT IS PRECISE=
LY THE PROBLEM WHY YOU NEED A SCALING SOLUTION FOR BITCOIN THAT WAS LIKE TH=
E FIRST RESPONSE TO SATOSHI ON THE CYPHERPUNK MAILING LIST) and you have to=
 show your transaction to everyone.  While sidechains imply that particular=
 subsets are the only ones interested in particular transactions, compare h=
ow large a sidechain-participant-set would be expected to be, to how many p=
eople learn of a payment over the Lightning Network.  If you want a sidecha=
in to be as popular as LN, then you expect its participant set to be about =
as large as LN as well, and on a sidechain, a transaction is published to a=
ll sidechain participants, but on the LN, only a tiny tiny tiny fraction of=
 the network is involved in any payment.  Thus LN is a superior scaling sol=
ution.  Now you might conter-argue that you can have multiple smaller sidec=
hains and just use HTLCs to trade across them (i.e. microchains).  I would =
then counter-counter-argue that bringing this to the most extreme conclusio=
n, you would have tons of sidechains with only 2 participants each, and the=
n you would pay by transferring across multiple participants in a chain of =
HTLCs and look, oh wow, surprise surprise, you just got the Lightning Netwo=
rk.  LN wins.