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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6EC6DC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 15:14:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 4A29141616
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 15:14:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id dWu97-AMPzVa
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 15:14:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
[IPv6:2607:f8b0:4864:20::b2d])
by smtp4.osuosl.org (Postfix) with ESMTPS id 7A6F8408E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 15:14:24 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id j2so6145454ybu.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jan 2022 07:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=dLn4mmBPPANTQ++qcPuaqL3wKBYl7dKmDu25KLHRQMA=;
b=pb3eGPFQWTHFk8NBaD6awYHBqzIeQDAjfeakQ58ye9jnY5YqP9O505sOL+BoZy1MGc
qmtCglDcawG+4eEtI6Fkcv5IpnADFMmD3rObo9I5dMOxfk5NWekWo2fdCfxgJXrLKn0V
KQV+OD/3li35/bnGtEbMVEmBOQMSNgSf2NbOqb3HJ4C90LJl1fq2buHsiKLJFM9JXfnt
nSw07VVMxSzHncRYPFdfKrS2LWUGy7oZe6Rrq1iip5m4vVxlOonOr29hgDKvDrGujAfC
R005ldsEHQtnr6Zqk29054GOt944ESocCZ5RO9vpVe3Ep0zUQHuW95eLSwxyrlEoPTUR
yDew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=dLn4mmBPPANTQ++qcPuaqL3wKBYl7dKmDu25KLHRQMA=;
b=VVtjK8VwfzhhC76K7Q+iUtnPC57E2/A35bK+fpfLGls1DcQF3g3fIK4FNPaMkuWtkp
0jUTQNJpMMjGu/4Ze0bPLOfhuvOqkfZJCzfK0DaN57rOiE3x7hT7e+RmFO4wh8WCjpPQ
00zcgA3RheKFm02Kr2I35kO981Ti1woLmxmJO/xVII+Qr2nne68ppzbwD34fgG7zAHlk
xlO7UvkZJEE1gcfkkO0WB4aAfuLGlMgcImjLCf1JOpRlarCgTa3ndULZu3qdGm3O51ko
mQaeN/zRfCZw03wd67hYV9boWDEi+sRHCGFb1clAXKpTk2Knh9oKtZxl7OI58i8y7WuH
NAKQ==
X-Gm-Message-State: AOAM533f7gM+rM7QC1k3JMVDwOkcExghdyCXlmBtx9dVS2Ju6wZXkROV
vDREsOWhEj4qm1MNAUMWJE++t/gtlOwUz9TLNrI=
X-Google-Smtp-Source: ABdhPJwGo7dCm6Pqcugj4ZwYY+V7jU0VsoDHPj7ZK0rBeuqhbLYmqO3U7m1CjYTlszyZuCpZUC6rMfBjFnC61s+qXsQ=
X-Received: by 2002:a25:7382:: with SMTP id
o124mr12742555ybc.318.1643382863288;
Fri, 28 Jan 2022 07:14:23 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
<CAMZUoKmU1cwUAQaBv5m8oo8H3TWBvgsZ_OkQaMC0n0+3cpFtWg@mail.gmail.com>
<CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
<CAMZUoKkvoJs0WtN71A_qRSwToP4YnY707WdW3C-KJYGXsmkjSw@mail.gmail.com>
In-Reply-To: <CAMZUoKkvoJs0WtN71A_qRSwToP4YnY707WdW3C-KJYGXsmkjSw@mail.gmail.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 28 Jan 2022 10:14:12 -0500
Message-ID: <CAPfvXfLWtDvgJYwQCaxnww5jyQkqFsi6aG0OUxtp3Okx_ab7Hw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cbdf5905d6a5e3ca"
X-Mailman-Approved-At: Fri, 28 Jan 2022 15:40:30 +0000
Subject: Re: [bitcoin-dev] 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: Fri, 28 Jan 2022 15:14:27 -0000
--000000000000cbdf5905d6a5e3ca
Content-Type: text/plain; charset="UTF-8"
> Technical debt isn't a measure of weight of transactions.
Sorry, my original sentence was a little unclear. I meant to say that the
notion that CTV is just a subpar waypoint en route to a more general
covenant system may not be accurate if it is a more efficient way (in terms
of chainstate/weight) to express highly useful patterns like vaults. In
that case, characterizing CTV as technical debt wouldn't be right.
> Our only option here is to be mindful of the long term implications of
the design choices we are making today.
Your points are well taken - I don't think anyone is arguing against
thinking hard about consensus changes. But I have yet to see a proposal for
covenants that is as efficient on-chain and easy to reason about as CTV is.
I also think there's some value in "legging into" covenants by deploying a
simple, non-recursive construction like CTV that services some very
important uses, and then taking as much time as necessary to think about
how to solve more existential problems, like UTXO scalability, that likely
require a recursive covenant construction.
There doesn't have to be mutual exclusion in the approaches, especially
when the maintenance burden of CTV seems to be so low. If we end up
deploying something that requires a wider variety of in-script hashing, it
seems likely that CTV's hash will be able to "free ride" on whatever more
general sighash cache structure we come up with.
--000000000000cbdf5905d6a5e3ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">> Technical debt isn't a measure o=
f weight of transactions. <br></div><div dir=3D"ltr"><br></div><div>Sorry, =
my original sentence was a little unclear. I meant to say that the notion t=
hat CTV is just a subpar waypoint en route to a more general covenant syste=
m may not be accurate if it is a more efficient way (in terms of chainstate=
/weight) to express highly useful patterns like vaults. In that case, chara=
cterizing CTV as technical debt wouldn't be right.<br></div><div><br></=
div><div>> Our only option here is to be mindful of the long term implic=
ations of the design choices we are making today.</div><div><br></div><div>=
Your points are well taken - I don't think anyone is arguing against th=
inking hard about consensus changes. But I have yet to see a proposal for c=
ovenants that is as efficient on-chain and easy to reason about as CTV is. =
<br></div><div><br></div><div>I also think there's some value in "=
legging into" covenants by deploying a simple, non-recursive construct=
ion like CTV that services some very important uses, and then taking as muc=
h time as necessary to think about how to solve more existential problems, =
like UTXO scalability, that likely require a recursive covenant constructio=
n. </div><div><br></div><div>There doesn't have to be mutual exclusion =
in the approaches, especially when the maintenance burden of CTV seems to b=
e so low. If we end up deploying something that requires a wider variety of=
in-script hashing, it seems likely that CTV's hash will be able to &qu=
ot;free ride" on whatever more general sighash cache structure we come=
up with.<br></div></div>
--000000000000cbdf5905d6a5e3ca--
|
