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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3A49CC001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 06:44:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 2950160B04
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 06:44:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Sn287rPfobXX
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 06:44:07 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0F769606B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 06:44:06 +0000 (UTC)
Date: Sat, 26 Feb 2022 06:43:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645857843;
bh=9aGziilQk5fRYkTPf/6D6qBha+aSL4L1/tJYyKgxEn4=;
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=pofWpgtpa9upWIcV9elD4mG5+37ep1V/lvJMgHCHhjgEk360CGOzzKWcCQNAMjC6X
7JOtT5Nm+7wLtNHoWa51fllPhSDZ29iD3VKqJu60fOaKjRAn0s2p2r91yHmBiXGZWS
FPUUY02PLCMAt21eShh8hXB08gFKiTNwaJHAscvmdjIyh14zi6IPXCuVSHO2ZhPekG
Ayp+hoVlDfNv9CQtX6vPUGy3N97W2hV/EOkQpMnKUf6zkn1mTnYJEFENwoDzqhbWvD
Zjq/9pbV/7A47vaBj3R2f/KNMhV7s7IvfAD3qBVj1qMzNf5RvBt90xu8dEl4PKFgF3
fEo+4ChpLa81Q==
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
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: Sat, 26 Feb 2022 06:44:10 -0000
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.
|
