1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8AB49C0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 12:03:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 6798D8134C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 12:03:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aSsGSIFCq-BR
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 12:03:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by smtp1.osuosl.org (Postfix) with ESMTPS id 7F29D8133B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Feb 2022 12:03:39 +0000 (UTC)
Date: Thu, 24 Feb 2022 12:03:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645704216;
bh=ZNmK0FPw//uSlbTsCCN2rOZQiEeuVYBHJSWUfKYmpQY=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=mG27QfEws2C5jAnDzxw6a8VpWM4dfoFK9YPjqzk7bW4fWWiLmyTK+FnLzi4wgi9Kh
dc0m2Fgwd8Vw9/JijgiDAWUJDVJ1N+s9VlPywkQbzaF5Gr0BHTKaEFP8lyBweRPtMD
Yq3SiVWSn/xnDkuH2pGciNm434/OMNjfBUHQROnRCcd8EjSZTJDyFEKu2j2wf7sabT
Zgtmlj8965ffSFolBKuTzvmSx9q/DxYuPgbl2BCCSCOtrGNXV1w33jRHv7Gyk4x1ip
0pd4ThKQbYjvIuYIofUs4s61BGxOHVRpk9JFjz8jzlzF1KtxCvU4iDT/JPbzPWeMxp
iyBRRiUtgXt4Q==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2022 12:03:40 -0000
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
|
