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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Return-Path: <dave@dtrt.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B14B9C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Apr 2021 22:00:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id A0D05605CB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Apr 2021 22:00:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dtrt.org
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 PbZIJOgNRYb7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Apr 2021 22:00:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from newmail.dtrt.org (newmail.dtrt.org
[IPv6:2600:3c03::f03c:91ff:fe7b:78d1])
by smtp3.osuosl.org (Postfix) with ESMTPS id 943B8605C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Apr 2021 22:00:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org;
s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=amxF9oZWGKKtjsRC7G1MdVFOTMD3oievt7MtNrk0gGU=; b=MY6jGgJaaOGPuwQq80vCmK95s1
ukN2NiHqfI6tSPxfwiYEleGG+A9IfH+sgAClYMWbI1c03VkzyHot6OfiTc+ruob71Dg1y4fiKQnYh
9vNrNnjDDCzr0vNRC2rFznehapTLGov0lmSQEY1gEA1ztF7p95ET11qZTFj+aKzP4Lqw=;
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1laQKF-0001va-HR; Sat, 24 Apr 2021 12:00:31 -1000
Date: Sat, 24 Apr 2021 11:59:00 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>
Message-ID: <20210424215900.nufcy6uzjzompdbs@ganymede>
References: <CAD5xwhj7jXSrdbfFJTYw-UzGgZTF0kz-Vr61juF0gJGLf2EKqQ@mail.gmail.com>
<20210423181550.xri2ravlwfe3vpc6@ganymede>
<CAD5xwhgnL_u1hS99HPTMBfQbRohgmajzNX4XiGYnN9mZDqjC7g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="el45hr5v3drrdepu"
Content-Disposition: inline
In-Reply-To: <CAD5xwhgnL_u1hS99HPTMBfQbRohgmajzNX4XiGYnN9mZDqjC7g@mail.gmail.com>
User-Agent: NeoMutt/20180716
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN
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, 24 Apr 2021 22:00:36 -0000
--el45hr5v3drrdepu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As in
> Script can represent things we know nothing about.=20
I guess I still don't understand your concern, then. If script can
represent things we know nothing about, then script commitments such as
P2SH, P2WSH, and P2TR also represent things we know nothing about. All
you know is what container format they used. For P2PK, bare multisig,
OP_RETURN, and other direct uses of scriptPubKey, that container format
is "bare" (or whatever you want to call it).
> Btw: According to... Oh wait... You?
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size=
-of-a-scriptsig-scriptpubkey
> the max size is 10k bytes.
I'm not sure what I knew at the time I wrote that answer, but the 10,000
byte limit is only applied when EvalScript is run, which only happens
when the output is being spent. I've appended to this email a
demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
999,000 bytes but ran into problems with bash's maximum command line
length limit). I've updated the answer to hopefully make it more
correct.
> Is it possible/easy to, say, using bech32m make an inappropriate message =
in
> the address? You'd have to write the message, then see what it decodes to
> without checking, and then re encode? I guess this is worse than hex?
If someone wants to abuse bech32m, I suspect they'll do it the same way
people have abused base58check[1], by using the address format's
alphabet directly. E.g., you compose your message using only
the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
the appropriate checksum.
[1] https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hash=
es
> But it seems this is a general thing... If you wanted an inappropriate
> message you could therefore just use bech32m addressed outputs.
Yes, and people have done that with base58check. IsStandard OP_RETURN
attempts to minimize that abuse by being cheaper in two ways:
1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
think) for OP_RETURN versus 40 bytes for a BIP141 payload.
Maximizing payload size better amortizes the overhead cost of the
containing transaction and the output's nValue field.
2. Exemption from the dust limit. If you use a currently defined
address type, the nValue needs to pay at least a few thousand nBTC
(few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC. For
OP_RETURN, the nValue can be 0, so there's no additional cost beyond
normal transaction relay fees.
Although someone creating an OP_RETURN up to ~1 MB with miner support
can bypass the dust limit, the efficiency advantage remains no matter
what.
> One of the nice things is that the current psbt interface uses a blind
> union type whereby the entires in an array are either [address, amount] or
> ["data", hex]. Having an address type would allow more uniform handling,
> which is convenient for strongly typed RPC bindings (e.g. rust bitcoin us=
es
> a hashmap of address to amount so without a patch you can't create op
> returns).
I don't particularly care how the data in PSBTs are structured. My mild
opposition was to adding code to the wallet that exposes everyday users
to OP_RETURN addresses.
> I would much prefer to not have to do this in a custom way, as opposed
> to a way which is defined in a standard manner across all software
> (after all, that's the point of standards).
I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
want to make sure this isn't underwhelmingly motivated or will lead to a
resurgence of block chain graffiti.
-Dave
## Creating an 11,000 byte OP_RETURN
$ bitcoind -daemon -regtest -acceptnonstdtxn
Bitcoin Core starting
$ bitcoin-cli -regtest -generate 101
{
"address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
"blocks": [
[...]
}
$ bitcoin-cli -regtest send '[{"data": "'$( dd if=3D/dev/zero bs=3D1000 cou=
nt=3D11 | xxd -g0 -p | tr -d '\n' )'"}]'
11+0 records in
11+0 records out
11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s
{
"txid": "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51=
",
"complete": true
}
$ bitcoin-cli -regtest getrawmempool
[
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
]
$ bitcoin-cli -regtest -generate 1
{
"address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh",
"blocks": [
"2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b"
]
}
$bitcoin-cli -regtest getblock 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106=
d216d3abb3a314c5604b 2 | jq .tx[1].txid
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
--el45hr5v3drrdepu
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmCElKQACgkQ2dtBqWwi
adPdng/8D6qnVxlUcojwsfQP7DY3jHfZHCvzwdcJrtFoZeYER+rIj1qEf1XpfC41
JFZIBt9KnuJOaRAQXbNennviDe+YcEwqg+Ubu1BRPFvU83W0F+lBiuIyqfh4xQ0h
a2hjfSaQRWmIRjUboPNKyvMOjOKoU/vZsMeviGQyFwIXzPfTD/RWD5bQagWb/ygy
HY+/wfM0a9754IqFEiH9s/kKMdNGhXwzEDkBF1Mpb7F9tWB/bStYpi58w31HNr6W
L+fDuFqhw0hoO6LTABqMAaWwCylex3Za1Ha5mfed0MTb2SB94opXA5M3uTH9TAlC
s2KCHF4CHKJ20oVe6BXYj/t4HB382ctItBVvYqi+hbyufHSYos4uEHqHm09S/Flj
Q0g4aFJe0s5hqh2FAX+1djJD0q1yihlfju3WFJdjaTolMjfQ8FyW/xlbGM4w3sg8
nUicgSCvuO0uEnX/e9xCH6oQEelhv6TDUqsUEya//2kfw7KDL2AR3XJr8DBClUb5
zOxHNq3gk1Vz8B0HrEFel0sRDVt6aRud6Jw5kxuXEl6WvtvXhpxQ+TNaU5r8Iuri
1bJlXq+AvV8MM6F2YXEyHrlIqlEI4Jxalx5MPWr7zHde0O7EV5R6LVUpTdvG5pa/
wWqK0k4aavOT5kyXS0YB0ohs18+mIVES1C3XdAZaGyTm+y9UCYw=
=iHdq
-----END PGP SIGNATURE-----
--el45hr5v3drrdepu--
|
