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
|
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 E6181C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Oct 2022 12:50:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B445560C08
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Oct 2022 12:50:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B445560C08
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=FkiUXm72
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.448
X-Spam-Level:
X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, 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 a0RYR-TeyYqz
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Oct 2022 12:50:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5141260BF7
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
[IPv6:2a00:1450:4864:20::629])
by smtp3.osuosl.org (Postfix) with ESMTPS id 5141260BF7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Oct 2022 12:50:21 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id sc25so25005097ejc.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Oct 2022 05:50:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=u+PJmf57gXt+8wn1HJUrPpQeqeEMua2+rkHEDa56Jjc=;
b=FkiUXm72NAsg/dkDTR8CWH1WI1J2kSq7N9BFs2kLf2eFMG0D9v2RX60RUVCAT/xmcX
Wq+30tBrhoijrlnI0gHjRmKyTnBRwyMAjutjryAvycM28BP72ruYfpUKS22NWEIs50Af
fprSFTKYswg7iOm/ZCTMve3gi2XNNy5mUHkvGpg8JMz7Q0toEyK4gS0azaVrPBn/NpnN
tuuuNQtro4ei+klkZJgVmjq82beXnvK0RaLvo374Y0QeQ1fBf2TE/m3v88PGtHIxYDUY
T6xJpB+cinHhmF4DjWVnT3WYUBjxuMjXZc5Q3TP0hRo6yg00nzEsVNk+Q3uTZ037ohP2
S/Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=u+PJmf57gXt+8wn1HJUrPpQeqeEMua2+rkHEDa56Jjc=;
b=qbHUIkznczXzwFeHKzunfgI4bJed9vRqLNFLVtwWwmgr0xLoDsZrjtYZh7GAm8G7Hg
VTE4Fc6i+xa5nf4Ox/wwRC+ovLE7ii4E6WmWYq2tucws56YJggERfY756hdAPONpQYOV
q0Quex8P4KbXq2ceW3nRsBfQw66gGjpYB8arz1YfY4E8duR+6Oc5YWArFoWRCRaszPYz
kXnehLnGpIvwt4VRLrlfyUECihd2NMx5gikGwdfcM5rzrbjdLOXHHeBPf2yAPR6xE+eh
slYi/ay6xOOpSbvrSFrU26jp0QNGppifBLvi3k7RBeU0oGKT0DcFvUzE5e5lAkDjf9rD
Im3g==
X-Gm-Message-State: ACrzQf3dcZbY2xaL/chPHvnoxEVEEbZIPndV1wtAsCcV2cznlqgaarV5
elNd6Qtw96Rc0VkjzI8gZl37sgJDMt72CYwrcEjnl4R8vyI=
X-Google-Smtp-Source: AMsMyM4ndwidE/x2OU1SujpK3JFClJNS5L8sT/RVEekiWhBeSsd+mgGBNthc0t5S1MjbInqFSO01CyDoEKsg0vV6bOw=
X-Received: by 2002:a17:907:3f8b:b0:783:2008:e562 with SMTP id
hr11-20020a1709073f8b00b007832008e562mr19000924ejc.261.1665492618903; Tue, 11
Oct 2022 05:50:18 -0700 (PDT)
MIME-Version: 1.0
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 11 Oct 2022 08:50:07 -0400
Message-ID: <CAB3F3DtNWajm669s9a=cs+Dft0PXDu1JHchzEw+yYLmRS+YSYQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ed04ea05eac1b7b3"
Subject: [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: Tue, 11 Oct 2022 12:50:23 -0000
--000000000000ed04ea05eac1b7b3
Content-Type: text/plain; charset="UTF-8"
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.
The PR is here with more relevant background and alternatives included in
the thread:
https://github.com/bitcoin/bitcoin/pull/26265
Please let us know if there's a fundamental issue with this approach, or
any other feedback.
Best,
Greg
--000000000000ed04ea05eac1b7b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello fellow Bitcoiners,<div><br></div><div>After looking =
at some fairly exotic possible transaction types, I ran into the current po=
licy limit requiring transactions to be 85 non-witness serialized bytes. Th=
is was introduced as a covert fix to policy fix for=C2=A0CVE-2017-12842. La=
ter the real motivation was revealed, but the "reasonable" consta=
nt chosen was not.</div><div><br></div><div>I'd like to propose relaxin=
g this to effectively the value BlueMatt proposed in the Great Consensus Cl=
eanup: 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.</div><div><br></div><div>The alternative would=
be to also allow anything below 64 non-witness bytes, but this seems fraug=
ht with footguns for a few bytes gain.</div><div><br></div><div>The PR is h=
ere with more relevant background and alternatives=C2=A0included in the thr=
ead:</div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/26265">ht=
tps://github.com/bitcoin/bitcoin/pull/26265</a><br></div><div><br></div><di=
v>Please let us know if there's a fundamental issue with this approach,=
or any other feedback.</div><div><br></div><div>Best,</div><div>Greg</div>=
</div>
--000000000000ed04ea05eac1b7b3--
|
