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
220
221
222
223
224
225
|
Delivery-date: Fri, 03 Oct 2025 08:54:11 -0700
Received: from mail-oi1-f187.google.com ([209.85.167.187])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDBNTKFG4EDRBGPD77DAMGQEGYGR2KA@googlegroups.com>)
id 1v4i6l-0002gu-GQ
for bitcoindev@gnusha.org; Fri, 03 Oct 2025 08:54:11 -0700
Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-43f58afca78sf3476127b6e.3
for <bitcoindev@gnusha.org>; Fri, 03 Oct 2025 08:54:11 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1759506845; cv=pass;
d=google.com; s=arc-20240605;
b=Twsx0l6eVh/j/KmL0tpmD5UwLyQ2Vr6xhS00g4+61l5KL+TLb5qAIrFIi7IrvMcYe8
RKmEbPjDdYqCKpirbn0eU3HU0sZBDK0xUo/Llfe+6TwjJspaaIHhVcDGLdz8qJfH3sdZ
vdxoiQsy+QsNzb6KwsqidzmEByV/WNzmZ+aXUmO/692fnP6zheTvVg/wo9Un1mDMPcEy
p8qtw5DOS69l2vbz7BctGopnVct4SeuT7CFlrGYEoTDgpp6GcDA1uxRf70AHyStXy/dJ
yohENbDiD+lxl6GQ+/Nnkaj4HmbVwDtPUEetLaZQcXCIhla7cElX2ghdRVrGxrCHCSjm
VLgA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:content-disposition
:mime-version:references:message-id:subject:cc:to:from:date:sender
:dkim-signature;
bh=SxlNsq4Fro/w8I0V5uq3S8zj1KihOlSRD7Ul+miJR6I=;
fh=6mbWndCC/MvxzhIqomCcw5ru1mOezZcLA0w/P/Ux2vc=;
b=GmH6S1znrWjTK6qwpr6bTIvsIhapMRoC8zCkkTvRB5hi12A7l7LWh7DK96/16pQe4b
5PjqJXEK2y0ez5QWtAAnbgKy2jmKpEC9pqWQbrTCc5eyYqBBBY7ufRiLFlYbl3r9Fvxf
RpI2dAMfJuvOfkw2w3VSiOawZhXhkAX/tbWJIz00j6rPtfqHwrDgHgFIcPQs3QJaUBLH
L5gaSfkGMHdwFiRdSvdTNxHwvqEXXkd3qn+3z7Rog2+JKEg72utyjm09wD610/Bd7fUz
ofRexfnwjn1JUR+kDR+uMVs+DuIn1XxKgZYsEAH9YPtCg72mwwAFGiWhGqGZ1SY9QGv6
t+0g==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1759506845; x=1760111645; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=SxlNsq4Fro/w8I0V5uq3S8zj1KihOlSRD7Ul+miJR6I=;
b=aXVWSX4vOrv5KZcgtoft5JhSmn5B60bkSgWM9w5JKrdmQtzT06cUy0HNBNeb9PyYSQ
x5I+SAGimma4a61bw7HCApNlgW0/iqNRf9Oud2PbiwPpC4lgqSFaFk7ySbsn3hk2kalx
kC4HAdgC7wilScmfXfyhdH0eV8exq4l3LUBlRYwUZ3gvr+ZSjVEDSwwH8si3wo4wtpAm
0Fn0+lmuqSOuefgzp4xV+SrsI4YXbeKQLMUn2M9nt8PnTgDrzTF8kZxH1LX/shqHRHJ9
DIpleco3I2fVBJ6I29zdSrMRbo9kCXdJyksDjCwNOVpS/5txfT6tesNfQwkGuCrN5L+H
b4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759506845; x=1760111645;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=SxlNsq4Fro/w8I0V5uq3S8zj1KihOlSRD7Ul+miJR6I=;
b=uaGS4B9Q5k7lnQnb2ckWlL9WlzjTxyc2ziLiQARpwBeDDeMqmjB4j5C3PLvENuDlK4
TOdqy8hg9VR96F2YDLlpyjgWilFaNulzh3wkny5yziqeC6eIq47sa7UymX2wlWg79Gvy
22RF3loqRr+o6x+xRrbkYBKMboPO5HTqD+B/CsywPN9uR14V6JVxp2s346kdrBAOEEE1
2MiyM4xb9jfM82oI7qr6eRtgk/ON8YAXdrz6fd21XObM4vmBrdDyzGq4oy0U6NyYHpEA
nBSP7cI5nntdbLFwkBR9YKJwQVkKhCUDkd6Rr1WXh0D2Iu4Ps137XADlN/RwKyt0Nz/x
O4gg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUK9J0LOQ4a65HRxro3SiVV+Fi0VnJmWJT2lE69GjciVG+K30q0yFvf1XhJ+2LO85qDhhafa2kQm1/s@gnusha.org
X-Gm-Message-State: AOJu0YyeKo6hkOzDvGNVJokohG0zLcSUkITahgz+Ku4TGSc8QlocH/iD
41v7vKQzUJr7RIUNP24m+nKWVQ36GWFk7Jayh7hjtr+YBDYrT0g2zhst
X-Google-Smtp-Source: AGHT+IF05mcpkWIxMX2LaoMsWSURuZNzfa1MjEQ8zLreuqIYOnIjXqEYXTGfGzznUeCv0V6IQRB+PA==
X-Received: by 2002:a05:6808:1506:b0:43f:7287:a5bd with SMTP id 5614622812f47-43fc179ba45mr2009244b6e.13.1759506845574;
Fri, 03 Oct 2025 08:54:05 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4s2U7z+EWCcvfI3zImzY51Kjfp8leSlw8Ktz8kgz+PtQ=="
Received: by 2002:a05:6820:26a:b0:646:73a2:101d with SMTP id
006d021491bc7-64e00dd0b90ls1163376eaf.1.-pod-prod-07-us; Fri, 03 Oct 2025
08:54:01 -0700 (PDT)
X-Received: by 2002:a05:6808:1506:b0:43f:7287:a5bd with SMTP id 5614622812f47-43fc179ba45mr2009132b6e.13.1759506841760;
Fri, 03 Oct 2025 08:54:01 -0700 (PDT)
Received: by 2002:a05:620a:88d:b0:80d:5a8b:a44e with SMTP id af79cd13be357-87a0e521f4cms85a;
Fri, 3 Oct 2025 08:43:23 -0700 (PDT)
X-Received: by 2002:ad4:5d43:0:b0:80e:4f6d:23be with SMTP id 6a1803df08f44-879dc8708bemr48887486d6.62.1759506182320;
Fri, 03 Oct 2025 08:43:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1759506182; cv=none;
d=google.com; s=arc-20240605;
b=SxnVEtH0Vk9MJL2s3Di0ZRzI8a7cdNTvllgNQfq5KyfwThxkJcOCrBqAcZNGvJZuia
Fmp1xhQCk1F1oOeFqtWTcSTtErLxZHsPKlFIhVENNB8m/oT4Gk2FHtWv6bSbHZyo3JZ8
v+4jPdBODxtejohxy0sow1fQ4ffblSEL6fwdNgwE5OTaVFiWP/PYd+GUhDxJ7b9QRUKY
Op0lDbtkCdGtqBQwSRlQ+xD1whqhkjBOVxm0xu/iWsVgDGIU48p9c9cK+H0DvFsrnSNM
GCSasvFvJSKwA3Xs/ycSadEZNQWMd1aFQSh4a5hosKLXjiK6S6XQ8x/kEbr6yTcUq5OP
Uqxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date;
bh=idixQTpDM0WccIyZWT/vyAlaX8byRJzb4WTI7kr2SEA=;
fh=Yq3ud+3qRm/huYxo70n2Iv8FSRuYgo9ERl1dwhQIx8Q=;
b=hLMA+dDTL/q5whwLKoPEQUxghdMQMTPP4l0KZFtCigOCO2MfpQOmjJotAsFhMBhCga
1LC+4iBLl1Hp8WGbLOJ0GDQq5gXSDduxwSQEFS9SKiaRGCa6S7XyVtfvmnQByKzyARDR
tmd3xROBdK0EidvLjcvYE0NHDaFwkeF5sYks4m9VKV8tX+GeVxetQCUVXcjG0oilEflu
PE9/FCSZ5uZVHhXtYaMsEh9Z9u5rK0aKSJrxhskvou7RtfJMdq9WLpP64OTcDbx9r73m
ASyDkD1SakMXVIavmb9sF7X8/7UiPMCpAEfR/tokvTwjUIs8Xl5wYvhnNuRPTxQ+tec4
AoOA==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193])
by gmr-mx.google.com with ESMTPS id 6a1803df08f44-878baa7024esi1617396d6.2.2025.10.03.08.43.01
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 03 Oct 2025 08:43:01 -0700 (PDT)
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Received: from aj@azure.erisian.com.au
by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <aj@erisian.com.au>)
id 1v4hvh-0000ik-2z;
Sat, 04 Oct 2025 01:42:58 +1000
Received: by email (sSMTP sendmail emulation); Sat, 04 Oct 2025 01:42:51 +1000
Date: Sat, 4 Oct 2025 01:42:51 +1000
From: Anthony Towns <aj@erisian.com.au>
To: PortlandHODL <admin@qrsnap.io>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Message-ID: <aN_u-xB2ogn2D834@erisian.com.au>
References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com>
X-Spam_score: -0.0
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
permitted sender) smtp.mailfrom=aj@erisian.com.au
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
On Thu, Oct 02, 2025 at 01:42:06PM -0700, PortlandHODL wrote:
> Proposing: Softfork to after (n) block height; the creation of outpoints
> with greater than 520 bytes in the ScriptPubkey would be consensus invalid.
> - Leaves enough room for hooks long term
> - Bitcoin could need it in the future?
One place where large scriptPubKeys could be useful is in script caching.
Suppose we have a future where complicated smart contracts are common;
eg perhaps some future version of lightning implemented using opcodes
from the great-script-restoration has a 9,000 byte script that is
used for every uncooperative close, and that lightning is so prevelant,
uncooperative closes are common.
In that scenario, we might like to be able to cache the 9,000 byte
script, and just invoke it by reference. One way to do that would
be to hardcode that script into consensus and soft-fork it in as a
new opcode. A more flexible alternative, however, would be to put that
script in our existing database, ie the utxo set, and look it up via its
36 bit txid/vout reference. To avoid permanently bloating the utxo set,
we could make such outputs expire after perhaps 100k blocks, and perhaps
increase the "weight" of creating such utxos by 10x, so that it's only
economical if the script is going to be used ~40x before it expires.
Using the utxo set here rather than creating a new database makes upgrades
easier; you don't have to rescan blocks to populate the script cache
database once you upgrade to a node version supporting script caching.
So I think there's potential uses for this flexibility that it wouldn't
be wise to just throw away.
(If you restricted the change to only applying to scripts that used
non-push operators, that would probably still provide upgrade flexibility
while also preventing potential script abuses. But it wouldn't do anything
to prevent publishing data)
> - Possible UTXO set size bloat reduction.
I don't think this works -- breaking up a scriptPubKey across multiple
utxos increases the utxo set bloat significantly, as in addition to the
scriptPubKey, each utxo includes a key (the 36 bytes for txid and vout),
an amount (8 bytes), a coinbase flag and a height (4 bytes), and likely
additional indexing data to keep lookups efficient.
If you're putting 10kB into the utxo set, then that's perhaps 50B of
overhead for a single entry (ie 0.5%); if you have to split it into 20x
500B entries with 50B overhead each, that's 1kB of overhead in total
(ie 10%).
> - Would make it harder to use the ScriptPubkey as a 'large'
> datacarrier.
This seems to be a bad goal to me; ie one that doesn't achieve anything
positive in reducing the bad things you want to prevent, but does make
things worse for other users you want to support. Breaking up data
and recovering it is straightforward, and already supported by various
Bitcoin-specific systems already; all breaking up the data achieves is
to use up slightly more resources. If the data being sent is already
economically marginal, that may result in less data being sent --
but only a similar reduction to what you'd get if fees increased at a
similar rate. When the data storage use case is not economically marginal,
it will instead just result in less resources remaining available for
whatever monetary activity is still taking place.
As far as the "but contiguous data will be regulated more strictly"
argument goes; I don't think "your honour, my offensive content has
strings of 4d0802 every 520 bytes, and as they say: if the data doesn't
flow, you must let me go" is an argument that will fly. Having the data
be separated by longer strings or otherwise structured differently isn't
a bigger difference between an image in a bmp, a jpg, or one dumped
in a zip file or mime-encoded, and none of those will let you avoid a
regulator's ire.
Cheers,
aj
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aN_u-xB2ogn2D834%40erisian.com.au.
|
