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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 777EBC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Feb 2023 02:07:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 3759E610D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Feb 2023 02:07:44 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3759E610D4
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=AZKo8xUM
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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
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 OJZuZ4ccepSp
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Feb 2023 02:07:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1506860D7B
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
[IPv6:2a00:1450:4864:20::636])
by smtp3.osuosl.org (Postfix) with ESMTPS id 1506860D7B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Feb 2023 02:07:42 +0000 (UTC)
Received: by mail-ej1-x636.google.com with SMTP id gr7so20166452ejb.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 03 Feb 2023 18:07:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=x9CvoHFOHxdomavzeOzaVFis8n4PtogKWskBpepckZo=;
b=AZKo8xUMk63rBLQqV0ljAjAFpSj99B6WflSC+IYD9gAxT16fTsjk8hyV5TW/JTr2bp
P27WyuqgpQLTwMERF9Pa236f73+ik33Ejqc6h4eDKY2j+MQoraEL0rN4aSMC0iIlNPjD
8GL7Ei0Ep9RvdZxop6HUhvC6X6lPhFuSDii8L1ek32wvNWFizW5KKf4JQ1z05wOmYJjw
JIdr03X5vj0bNFwjgRoOaMx8OuVp2SKUJkG43jvNuSw2aBX1M/9+C8/VMl/dUdWC+x9o
vIY6R7Y72ZLVbZozSSg2SQvUkCmKE5x9COAGeKpKScNztiCN1u8Pe272Qc+Tv8ggZSV6
RZQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=x9CvoHFOHxdomavzeOzaVFis8n4PtogKWskBpepckZo=;
b=1QxTDmwbqOnCpDHFEM0QO2AhzXpcMaSiIYkNCpl2zFTCTd1zHcUNoHYLVUxI9xLSxr
XYxttBjUmtFhIMa6tLsqRo/5iQEjAJEtTzfQsMGeBDiv+14SlQm3DGFoHQ8u4927GKxJ
LFVK3EB2twpvxpgMnlesqIB5J4JuxcihYwmNv6Cp4SaOEndCXPiqzmhVbcV8vMqmZmc3
6bC3IqVxdA2FGWLV/ToMkAD+kAkKxT9CPV76nw9Ytkgo4tOY/BUDAoiO5J6h2ePkx0gw
6uol3Z94f2toKG8bMTNfmH4EUd+1rV2BClQ9CsemWGuMuQKKd3n/MeX5I02v3wnMXZ0j
6+9Q==
X-Gm-Message-State: AO0yUKVSpdiKYZKQnLbYotC9LgC2P4/K3BJaW4jjuUncgDhLFJQGbXZC
/IldzTXtetHTePMK1aOJb7SoeOGQUlMvoKjI/8KXsl8sZ6I=
X-Google-Smtp-Source: AK7set+Pq2WPqoxANCIlM+/ryqaXWkcfeUhUvx4vR2eudDPLB99TdAA6yHmiPg3XzdH68HmzDuIabiJYw9X7cf++wiU=
X-Received: by 2002:a17:907:6087:b0:889:7bef:3a9d with SMTP id
ht7-20020a170907608700b008897bef3a9dmr4016509ejc.150.1675476460931; Fri, 03
Feb 2023 18:07:40 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXf+N8aF+bqjGzpfDrhCYg7ngciSDCpUnCMHD+k5F+m3oWA@mail.gmail.com>
<CAB3F3DuDODUxB5aK4VFWa8sKFCkZfOj6Vjb+Wp39opyt8MNnEA@mail.gmail.com>
<CAB3F3DtrSFPmperGJJAUDZj7vt9aHgvkc0b5Pts3+mq5fTuWXA@mail.gmail.com>
<CAB3F3DvToF_fia+X5SQi-L=BDYGLpzr8nNHqjtFBUjLMbyPE9Q@mail.gmail.com>
<Y9vOGVMJx1b9CPYq@petertodd.org>
<CAB3F3Du2XsHCh5o5S84XKKizTkrTFJJ-j42-qunyuSRkwX7H_Q@mail.gmail.com>
<Y9vRjQVnZzA8Bx/s@petertodd.org>
<CAB3F3DvumE-r+LGm8ivooPD9qfzFs-NK9Ve06Ew1EMAifSx8dw@mail.gmail.com>
<Y9wbjsmPO+nyM267@petertodd.org>
<CAB3F3Ds7Ux8MWnY-9Agehpk0hZx_xgeFmZG7hUjMkfe48T5GPA@mail.gmail.com>
<Y92GY7s1U4P9fC/f@petertodd.org>
In-Reply-To: <Y92GY7s1U4P9fC/f@petertodd.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 3 Feb 2023 21:07:29 -0500
Message-ID: <CAB3F3Dtuxu8m6+pU_xBwh=35MyPF90OSnB4vhaNbKpr_ap2shw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000004891cc05f3d643e2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF
againstpackage limit pinning
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, 04 Feb 2023 02:07:44 -0000
--0000000000004891cc05f3d643e2
Content-Type: text/plain; charset="UTF-8"
I'm not particularly persuaded, but also not wedded to either idea.
Fixed up tests for the OP_TRUE case here:
https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
On Fri, Feb 3, 2023 at 5:10 PM Peter Todd <pete@petertodd.org> wrote:
> On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> > stack,
> > which plays better with other standardness rules.
> >
> > What other standardness rules? MINAMALIF? How does that interact with the
> > proposal?
>
> It makes sense to require scripts to leave just a single OP_TRUE on the
> stack
> at the end of execution, as otherwise that can be a source of malleability
> in
> certain circumstances where the scriptSig ends up providing the OP_TRUE. I
> don't believe we actually implement this as a rule right now. But you could
> easily imagine that happening in a future upgrade.
>
> Leaving an OP_2 on the stack doesn't achieve that and would require a
> special-cased workaround. Spending the time now to do the obvious thing -
> use
> OP_TRUE as the canonical anyone-can-spend output - avoids this issue.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--0000000000004891cc05f3d643e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not particularly persuaded, but also not wedded to=
either idea.<div><br></div><div>Fixed up tests for the OP_TRUE case here:=
=C2=A0<a href=3D"https://github.com/instagibbs/bitcoin/tree/ephemeral-ancho=
rs-true">https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true<=
/a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Fri, Feb 3, 2023 at 5:10 PM Peter Todd <<a href=3D"mailto:pe=
te@petertodd.org">pete@petertodd.org</a>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex">On Thu, Feb 02, 2023 at 03:47:28PM -050=
0, Greg Sanders wrote:<br>
> > OP_TRUE is the obvious way to do this, and it results with a 1 on=
the<br>
> stack,<br>
> which plays better with other standardness rules.<br>
> <br>
> What other standardness rules? MINAMALIF? How does that interact with =
the<br>
> proposal?<br>
<br>
It makes sense to require scripts to leave just a single OP_TRUE on the sta=
ck<br>
at the end of execution, as otherwise that can be a source of malleability =
in<br>
certain circumstances where the scriptSig ends up providing the OP_TRUE. I<=
br>
don't believe we actually implement this as a rule right now. But you c=
ould<br>
easily imagine that happening in a future upgrade.<br>
<br>
Leaving an OP_2 on the stack doesn't achieve that and would require a<b=
r>
special-cased workaround. Spending the time now to do the obvious thing - u=
se<br>
OP_TRUE as the canonical anyone-can-spend output - avoids this issue.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--0000000000004891cc05f3d643e2--
|
