MIME-Version: 1.0
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>
In-Reply-To: <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 25 Feb 2022 23:38:03 -0600
Message-ID: <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001092ad05d8e539d0"
Cc: 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

--0000000000001092ad05d8e539d0
Content-Type: text/plain; charset="UTF-8"

@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
<https://github.com/fresheneesz/bitcoinThroughputAnalysis> 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
>

--0000000000001092ad05d8e539d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@ZmnSCPxj<br>&gt; we have already rejected Drivechains<br>=
<br>I also think this is kind of dubious. I don&#39;t remember consensus be=
ing to &quot;reject&quot; drivechains, as much as consensus was that it was=
n&#39;t a priority and there wasn&#39;t a lot of interest in doing on it fr=
om many people (I&#39;m sure Paul could comment further on that). <br><br>&=
gt; sidechains on Drivechains become a block size increase.<br><br>While th=
is would be true for those who opt into a particular drivechain, I think it=
s 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 node=
s that don&#39;t care about drivechains=C2=A0would not see a blocksize=C2=
=A0increase.=C2=A0<div><br></div><div>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&#39;t care about =
drivechains. The <a href=3D"https://github.com/fresheneesz/bitcoinThroughpu=
tAnalysis" target=3D"_blank">important things</a> about a &quot;normal&quot=
; blocksize increase are:</div><div><br>A. It increases the machine resourc=
es necessary for IBD, transaction relay, and validation</div><div>B. It pro=
bably increases the growth rate of the UTXO set, increasing memory necessar=
y to store that.</div><div>C. It increases the cost of storing the blockcha=
in on non-pruned nodes</div><div>D. It increases the average propagation ti=
me of new blocks, which increases miner centralization pressure.=C2=A0</div=
><div><br></div><div>The existence of drivechains=C2=A0with every miner opt=
ed into (some of) them would only negatively impact item D. Normal bitcoin =
nodes wouldn&#39;t need to use any extra resources if they don&#39;t care a=
bout drivechains. And miners would only have additional centralization pres=
sure proportional to what drivechains they&#39;re opted into. The reason fo=
r that is that if a miner is opted into drivechain=C2=A0X, and propagation =
of transaction data for drivechain=C2=A0X is significantly slower than the =
normal bitcoin network, a miner may not have the latest drivechain=C2=A0X b=
lock to merge mine on top of. However that miner can still mine bitcoin wit=
h no additional latency, and so that centralization pressure is minimal unl=
ess a significant fraction of the miner&#39;s revenue comes from drivechain=
s with slow data propagation. Beyond that, by my calculations, miner centra=
lization is quite far from being significantly affected by blocksize increa=
ses. So unless drivechains become the dominant use case of the bitcoin bloc=
kchain, this really isn&#39;t something that I expect to cause any substant=
ial miner centralization or other blocksize related problems.</div><div><di=
v><br></div><div>ZmnSCPaj, are you arguing that drivechains=C2=A0are bad fo=
r bitcoin or are you arguing that it would be unwise to opt into a drivecha=
in? Those are very different arguments. If drivechains=C2=A0compromised thi=
ngs for normal bitcoin nodes that ignore drivechains, then I agree that wou=
ld be serious=C2=A0reason to reject drivechains=C2=A0outright and reject th=
ings that allow it to happen. However, if all you&#39;re saying is that peo=
ple can shoot themselves in the foot with drivechains, then avoiding drivec=
hains=C2=A0should not be a significant design consideration for bitcoin but=
 rather for those who might consider spending their time working on drivech=
ains.=C2=A0</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Feb 24, 2022 at 6:03 AM ZmnSCPxj via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Good morning aj,<br>
<br>
&gt; &gt; Logically, if the construct is general enough to form Drivechains=
, and<br>
&gt; &gt; we rejected Drivechains, we should also reject the general constr=
uct.<br>
&gt;<br>
&gt; Not providing X because it can only be used for E, may generalise to n=
ot<br>
&gt; providing Y which can also only be used for E, but it doesn&#39;t nece=
ssarily<br>
&gt; generalise to not providing Z which can be used for both G and E.<br>
<br>
Does this not work only if the original objection to merging in BIP-300 was=
 of the form:<br>
<br>
* X implements E.<br>
* Z implements G and E.<br>
* Therefore, we should not merge in X and instead should merge in the more =
general construct Z.<br>
<br>
?<br>
<br>
Where:<br>
<br>
* E =3D Drivechains<br>
* X =3D BIP-300<br>
* Z =3D some general computation facility<br>
* G =3D some feature.<br>
<br>
But my understanding is that most of the NACKs on the BIP-300 were of the f=
orm:<br>
<br>
* X implements E.<br>
* E is bad.<br>
* Therefore, we should not merge in X.<br>
<br>
If the above statement &quot;E is bad&quot; holds, then:<br>
<br>
* Z implements G and E.<br>
* Therefore, we should not merge in Z.<br>
<br>
Where Z =3D something that implements recursive covenants.<br>
<br>
I think we really need someone who NACKed BIP-300 to speak up.<br>
If my understanding is correct and that the original objection was &quot;Dr=
ivechains are bad for reasons R[0], R[1]...&quot;, then:<br>
<br>
* You can have either of these two positions:<br>
=C2=A0 * R[0], R[1] ... are specious arguments and Drivechains are not bad,=
 therefore we can merge in a feature that enables Recursive Covenants -&gt;=
 Turing-Completeness -&gt; Drivechains.<br>
=C2=A0 =C2=A0 * Even if you NACKed before, you *are* allowed to change your=
 mind and move to this position.<br>
=C2=A0 * R[0], R[1] ... are valid arguments are Drivechains are bad, theref=
ore we should **NOT** merge in a feature that implements Recursive Covenant=
s -&gt; Turing-Completeness -&gt; Drivechains.<br>
<br>
You cannot have it both ways.<br>
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.<br>
<br>
&gt; I think it&#39;s pretty reasonable to say:<br>
&gt;<br>
&gt; a) adding dedicated consensus features for drivechains is a bad idea<b=
r>
&gt; in the absence of widespread consensus that drivechains are likely<br>
&gt; to work as designed and be a benefit to bitcoin overall<br>
&gt;<br>
&gt; b) if you want to risk your own funds by leaving your coins on an<br>
&gt; exchange or using lightning or eltoo or tumbling/coinjoin or payment<b=
r>
&gt; pools or drivechains or being #reckless in some other way, and aren=
9;t<br>
&gt; asking for consensus changes, that&#39;s your business<br>
<br>
*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.<br>
<br>
(Admittedly, Drivechains does get into a Mutually Assured Destruction argum=
ent, so that may not hold.<br>
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.<br>
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.)<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000001092ad05d8e539d0--