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
183
184
185
186
187
188
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 140AAC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Oct 2022 00:08:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D6A2160D54
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Oct 2022 00:08:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D6A2160D54
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=i/xB6+Dz
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 iSMJv-eeDw4L
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Oct 2022 00:08:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 500D360C02
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
[IPv6:2a00:1450:4864:20::62d])
by smtp3.osuosl.org (Postfix) with ESMTPS id 500D360C02
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Oct 2022 00:08:06 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id sc25so3270418ejc.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 17:08:06 -0700 (PDT)
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=FRHrtMaOJSm5F0CXoARoatepEYjf6HKM4FbMY1GXj7A=;
b=i/xB6+DzNnOCqPnPvXnD+90O6FW/Tp4XD5/EX9C+v4JJQ1WSK45GO1kHoTEKYF6imP
N2hgNd6CI3Es//WO+GDlcCoDJfCLHvEoICLOEQUh6YVKiIc5UQiZYYTcmebKd9IUm1OR
Q9bQSOIG0qxb4OKG/qMGqE/8Otli8nrbHtMugu9jOSxZ81KlqV3e/qEXRTJvAywtrRJO
RNunY90BieK8DhC6IIaqgvIL739JjSkI/978gZ4tUuvs6LMcAGzJ+CF56rXab/cAxTEs
T6t2lt7G/+fwdqpPPxFgr9vq9Xb6soVY9tycSiqUHkHZjqF316DkPGcn0thrwCvkyy72
BzeQ==
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=FRHrtMaOJSm5F0CXoARoatepEYjf6HKM4FbMY1GXj7A=;
b=ZO2FHzLj2cRPK+mYH63RramxynVKI+b06yY4URWbEj6U5TozBJDDXDpCqHURcSwBv7
V3LVhSeyaikF6VFXiG4aFGehe6qTrcorwqXbfAg3HmG26fakFuIVowV5/KZh+4AH8HEd
wYD0CvjjHjVBfyVdUI5xpq3MZND1tDlVU63SrhWfAkGQNt+/dTig9LOr4fTPVXusRjTz
+pAc3/xSBP2uP5ymwfQAq14UuuCnkz3F1B9DRQOiFPJY0gul3J1RU8TumKCh9o8u3DgN
tNZYuBn0JJrxkf01bQbRJlcDkE0xqjvZE3NfL2FJYL+AB7ZUkf3Y6XVRgW/KMd3bIihz
iMCg==
X-Gm-Message-State: ACrzQf1kpGRucvOEaWjcTFQSMCD4B4jB2iqg37kWdlveLkbrwnoiPK2n
YMwpD4Z9SnqVCSpDVNeypTxrd8mSvGfIwVq7J84t2wIF
X-Google-Smtp-Source: AMsMyM4dizuPSYbTP+bPoSJhI0EDJYnAZS7a+SwqJBal51/Ol1pe8vuRWKmCfcXFRik+/0l/oUTledzHeF5n/SsYt90=
X-Received: by 2002:a17:907:2702:b0:78e:e94:2ac4 with SMTP id
w2-20020a170907270200b0078e0e942ac4mr13017975ejk.679.1666310884372; Thu, 20
Oct 2022 17:08:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAB3F3DtNWajm669s9a=cs+Dft0PXDu1JHchzEw+yYLmRS+YSYQ@mail.gmail.com>
<Y1HX3cI7k91pTFUf@petertodd.org>
In-Reply-To: <Y1HX3cI7k91pTFUf@petertodd.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 20 Oct 2022 20:07:54 -0400
Message-ID: <CAB3F3DtfHHai2q4s9LehK63iAEMUmkpTWaP8dwJ+N1vU7+EBag@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000059374005eb803ccc"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Relaxing minimum non-witness transaction size
policy restriction
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, 21 Oct 2022 00:08:08 -0000
--00000000000059374005eb803ccc
Content-Type: text/plain; charset="UTF-8"
I don't doubt the use case(it's why I opened the issue!). I didn't want the
proposal to die in case people found it odd that 61, 62, 63, but not 64
bytes ended up being broadcast able.
Perhaps this is not an issue, especially since this isn't a consensus
change like the Great Consensus Cleanup. Willing to change my proposal and
PR if people have no strong objections.
Greg
On Thu, Oct 20, 2022, 7:21 PM Peter Todd <pete@petertodd.org> wrote:
> On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > Hello fellow Bitcoiners,
> >
> > After looking at some fairly exotic possible transaction types, I ran
> into
> > the current policy limit requiring transactions to be 85 non-witness
> > serialized bytes. This was introduced as a covert fix to policy fix
> > for CVE-2017-12842. Later the real motivation was revealed, but the
> > "reasonable" constant chosen was not.
> >
> > I'd like to propose relaxing this to effectively the value BlueMatt
> > proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
> > allow a single input, single output transaction with 4 bytes of OP_RETURN
> > padding, rather than padding out 21 bytes to get to p2wpkh size.
> >
> > The alternative would be to also allow anything below 64 non-witness
> bytes,
> > but this seems fraught with footguns for a few bytes gain.
>
> What footguns exactly? Spending a single input to OP_RETURN with no
> payload is
> a valid use to get rid of dust in the UTXO set.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--00000000000059374005eb803ccc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I don't doubt the use case(it's why I opened the =
issue!). I didn't want the proposal to die in case people found it odd =
that 61, 62, 63, but not 64 bytes ended up being broadcast able.=C2=A0<div =
dir=3D"auto"><br></div><div dir=3D"auto">Perhaps this is not an issue, espe=
cially since this isn't a consensus change like the Great Consensus Cle=
anup. Willing to change my proposal and PR if people have no strong objecti=
ons.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Greg</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Oct 20, 2022, 7:21 PM Peter Todd <<a href=3D"mailto:pete@petertodd.=
org">pete@petertodd.org</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Tue, Oct 11, 2022 at 08:50:07AM -0400, Greg Sanders via bitcoin-dev =
wrote:<br>
> Hello fellow Bitcoiners,<br>
> <br>
> After looking at some fairly exotic possible transaction types, I ran =
into<br>
> the current policy limit requiring transactions to be 85 non-witness<b=
r>
> serialized bytes. This was introduced as a covert fix to policy fix<br=
>
> for CVE-2017-12842. Later the real motivation was revealed, but the<br=
>
> "reasonable" constant chosen was not.<br>
> <br>
> I'd like to propose relaxing this to effectively the value BlueMat=
t<br>
> proposed in the Great Consensus Cleanup: 65 non-witness bytes. This wo=
uld<br>
> allow a single input, single output transaction with 4 bytes of OP_RET=
URN<br>
> padding, rather than padding out 21 bytes to get to p2wpkh size.<br>
> <br>
> The alternative would be to also allow anything below 64 non-witness b=
ytes,<br>
> but this seems fraught with footguns for a few bytes gain.<br>
<br>
What footguns exactly? Spending a single input to OP_RETURN with no payload=
is<br>
a valid use to get rid of dust in the UTXO set.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://pet=
ertodd.org" rel=3D"noreferrer noreferrer" target=3D"_blank">petertodd.org</=
a><br>
</blockquote></div>
--00000000000059374005eb803ccc--
|
