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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id BE6BAC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 23:33:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 97D64841F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 23:33:20 +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 HqmkdPfbxFKZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 23:33:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.osuosl.org (Postfix) with ESMTPS id CA0B983313
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2022 23:33:19 +0000 (UTC)
Date: Fri, 04 Mar 2022 23:33:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1646436797;
bh=BrwoxJtrl5NyQmbDUT7vlPzAjdijA74f6ByjpGz6tpo=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
b=q0L0mKoXzPXF52XtlKPyEXLf1QMiho6dYDYFZprwI6j7ZAYrqXT9EA6j7c6rHL+vT
8/keTvm37lLoM5EW7txJNalYaPTNzgFxPb32YRXxnEH29KSHmWboBgEK6hI9EUZmEx
rrIOdw9e9xygT11dyq+4ojQ/9j8obbvqRFex4RpbnHSO/AhiG1maVHuVvwrpYelL9r
ZuVgpYRHTtSBDKGU5O9f6BBO7sFlqcLFknFr1f5OuRnvatG+lfBPp0p0nYzM2PTAdA
CSc9WoKA7aZe7fFjGVGEc6M0aBmOg/IbjJLdeehNtzKOzHudeifwB5rayHNMepGWlZ
KuNjUj3GCmKbg==
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
In-Reply-To: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
References: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX,
Turing Completeness, and other considerations
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, 04 Mar 2022 23:33:20 -0000
Good morning Jeremy,
Umm `OP_ANNEX` seems boring ....
> It seems like one good option is if we just go on and banish the OP_ANNEX=
. Maybe that solves some of this? I sort of think so. It definitely seems l=
ike we're not supposed to access it via script, given the quote from above:
>
> Execute the script, according to the applicable script rules[11], using t=
he witness stack elements excluding the script s, the control block c, and =
the annex a if present, as initial stack.
> If we were meant to have it, we would have not nixed it from the stack, n=
o? Or would have made the opcode for it as a part of taproot...
>
> But recall that the annex is committed=C2=A0to by=C2=A0the signature.
>
> So it's only a matter of time till we see some sort of Cat and Schnorr Tr=
icks III the Annex Edition that lets you use G cleverly to get the annex on=
to the stack again, and then it's like we had OP_ANNEX all along, or withou=
t CAT, at least something that we can detect that the value has changed and=
cause this satisfier looping issue somehow.
... Never mind I take that back.
Hmmm.
Actually if the Annex is supposed to be ***just*** for adding weight to the=
transaction so that we can do something like increase limits on SCRIPT exe=
cution, then it does *not* have to be covered by any signature.
It would then be third-party malleable, but suppose we have a "valid" trans=
action on the mempool where the Annex weight is the minimum necessary:
* If a malleated transaction has a too-low Annex, then the malleated transa=
ction fails validation and the current transaction stays in the mempool.
* If a malleated transaction has a higher Annex, then the malleated transac=
tion has lower feerate than the current transaction and cannot evict it fro=
m the mempool.
Regards,
ZmnSCPxj
|
