summaryrefslogtreecommitdiff
path: root/18/9069ed9100344b3e3a912891a176203e6581c0
blob: b3cdba6a1d18a57bf4b5fbfcf1e3aa4b80e2f542 (plain)
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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
Delivery-date: Thu, 02 Oct 2025 16:42:29 -0700
Received: from mail-oa1-f57.google.com ([209.85.160.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD5MDHHN4EIBBWU37TDAMGQEGTAGIRQ@googlegroups.com>)
	id 1v4SwO-0005RN-G0
	for bitcoindev@gnusha.org; Thu, 02 Oct 2025 16:42:29 -0700
Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-30ccec20b9bsf2697515fac.2
        for <bitcoindev@gnusha.org>; Thu, 02 Oct 2025 16:42:28 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1759448542; cv=pass;
        d=google.com; s=arc-20240605;
        b=Gyt5QyUvAtIU23XhRgrh5LOVf8Ae2DyV/mR4j0beO3qSriuEwrP39cLcU18lx+d5Cu
         YFw8hQXHIbJGHI06iqS5SNpeOi5F+LZ8SqIUivX1b2YtySWcrWlwzfB3/XNcu0Zzu8UX
         SalgrdnjB1lNg+EYc+nCvbTf547V80GUO/BjB4EihsL4uWRX3P5/ZusFYcG0GsZpjccb
         RBo+dRiOR+/D9DJKzSklXirPCYGKEvjcU2rlsNJHq5Ii43ymxukxKSjUon8f3VLb5yI6
         yBSTndv/EnS6y4hN8E2wPHcON7GctNBxTw1HnjflYVub7Kkswo6OtCCG7nTVe5C7buME
         sQLg==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature;
        bh=vMhYN5WMI7yL4+c+FM5p5q/q0Si9RMUdbSeFl1ncY8E=;
        fh=pq6xLEwSB4mfERltCS4XwcOSMmtNwSAoHTSCNMORVHs=;
        b=OWDC5qEg+32LhZzGNisKGfaZNjKLerSJgRWudVHzWtKG4bztaIfVNeGN+QvGd9yUDv
         yom6HjOI3z30hIeTfOZwy/qi79HGZI6B9FX4XF9zCCYp0ulWcGdIP5ABAkqpYiPA6ATf
         YZbKQKNGgHulN6UEXV5HUENZzXdyK2V+3fXyI05L4GpZ+snMTxeOMfdB4x9rRcScjaNz
         Bg3ys6eyfFykUq+aVC+1XPVHIxG495wzGc/PzzUI/1KE2vPOY/ArYyQNHPWrijlerIfL
         Sl6ChNt/3tdxIPTigR9clQGoTZoStDAiqNTrMyAcBqnVrvKaXrlzA/W8PW0lWaRLh5fP
         cA9g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b="Ejf/7iUC";
       spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=earonesty@gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1759448542; x=1760053342; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vMhYN5WMI7yL4+c+FM5p5q/q0Si9RMUdbSeFl1ncY8E=;
        b=abMy9PVQIywa5lTi9bPgsdUMuDAFWRBM062pOuYLqa5ZL4WSScboNrdbS3uBdunwJm
         /BxV5YvnbgIFHjvJkzunMqhq3t5tpKGEifyj6q40HhpnpIdPgzke9jTQOnV9KiwTakWb
         T4TvgjnzhSDk/Ta5cv96EYRgpVhSiz+rmZNrPgKuqRi7MMQagSFyMEqGGGP5K4UAhYbh
         lJgl9uJp8aQ5CRQWxOSN3055puSIQp+MXAp+dpk9YrbC7n8FgHPcDvZImM3oQLZGKF3Q
         B2rzt+3GPeKVsGg+AKWhLPYXFvDqW/Q7n2h+qWWDuwIw89bg9vkanO2kZYI2Y/t7f5pU
         WTFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759448542; x=1760053342;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=vMhYN5WMI7yL4+c+FM5p5q/q0Si9RMUdbSeFl1ncY8E=;
        b=RcTSAGOkFXGZaggV2J0tvimjA+45fyIHGIDK56o6PyCKBuK2nBqlxl5pbUZG5T8kFD
         OZmwhuoStATGqGaqlFSFy7we41qha6PE84R+nwq6v9MMS5XOsg5KsdSznU7PB3XoiOwV
         43hKAj+vunIo71xyeU/FbtdiYlR8qlvQXxzsrJOyP+h1vo5Iv96dHF3D4MKZnXrhqHO9
         ay0HkfjaW62r4wtXlcWoa//DohfBxZVe4Gx1IOKe+g+h7l9UvF5qZk9lp1mD9edfSNdX
         22CKRMDn0A2aKTLPVqbgKO+W24xWyq5gqNIgxy/8D4ZlKaVZ4lB9I5h8+EAW7dRjkD97
         kN1A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWpTjnqRpueVVmlwfnRpIyUaqNRvf9LWx4U08qq+tunuKNNKSc1aeekLvOzT2MnuPHe5KQTShzczf53@gnusha.org
X-Gm-Message-State: AOJu0Yzp4HswA0g5EDUS/h5ClYkF2vcL4jOXuZS72KjBjuPfcfO3Yt3f
	gRt+95YdMOUDZmyVe4L+xNloG3obEPU3tTKPv0yBo1JlFpI0y80zK5cU
X-Google-Smtp-Source: AGHT+IFRiiWXd6DDS+q/Kwas0ZO45u2ihcUNULYoIylugXxiMRnJ/457nBTNTihe4sFwrBGEl0JgYA==
X-Received: by 2002:a05:6870:5253:b0:345:c0a7:5fa3 with SMTP id 586e51a60fabf-3b0f53a8db4mr784955fac.20.1759448542332;
        Thu, 02 Oct 2025 16:42:22 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd70mrkQZHWmE0llSPb/i3/mleNI6dc7qh7rH/EL0QAnnA=="
Received: by 2002:a05:687c:5b:20b0:319:c528:28df with SMTP id
 586e51a60fabf-3abfdecafbels510172fac.1.-pod-prod-08-us; Thu, 02 Oct 2025
 16:42:17 -0700 (PDT)
X-Received: by 2002:a05:6808:f11:b0:43d:3898:adc1 with SMTP id 5614622812f47-43fc176d5c8mr504338b6e.8.1759448537799;
        Thu, 02 Oct 2025 16:42:17 -0700 (PDT)
Received: by 2002:ab3:1992:0:b0:2c3:d086:1a03 with SMTP id a1c4a302cd1d6-2c9e0f01258msc7a;
        Thu, 2 Oct 2025 16:40:05 -0700 (PDT)
X-Received: by 2002:a05:6512:b98:b0:578:fc5e:893a with SMTP id 2adb3069b0e04-58cb96629edmr259116e87.5.1759448401031;
        Thu, 02 Oct 2025 16:40:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1759448401; cv=none;
        d=google.com; s=arc-20240605;
        b=HNyBheM4ggcobgUtQR5vAHAjgEQO5MX+ztBbFiNlpLplyZfIuUTNvB+Vtb58mT12wv
         tZNKoG7TZUoZhMesNHRHZoTs46LGSzALRpsv2Da+V/iBfzNp7i1Yn6J3/M4dAdXXqwNA
         LhHu/fzUSn/yZ1LPDSt8MAae8MO7k5rVAv3b6c2/7PgMw1WfD028sg9M5olZUgNT3UHp
         J9PDxN1kE7dQijlIQk/aTNoMHgGeNAhIpCZN7yLP5YpHobX3c+5We6CN9TcafSO9zTk5
         Lk3VIa2KnYTvPTdovdDJ24G6ce8eG8Uj/mRu3KQizS6TuaZnuBjd32tqk91/SpNchq+k
         z6fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=QEYuBHa77aJlSu01ngLmpeExBM/twirvcn1PzPy4iWo=;
        fh=alK3DWCfRpGgxsv9FH0Iv52rsOY89sPdSSpigKQdDbQ=;
        b=U93AqsqkAczW7t21YnuQdyZZN06faaLz5p+dq90lf93u5wRE1/5/42LBe0w+rz7jyG
         6xCoMOJhJc4pUGpQ0tQIacW6O4YaQV5qmkVIQvlvLVX/J8NGxLJp87xNy4Tf0J2kEcFW
         //4uPne7XN1zLrzCFwvZ3dC8S82KhVTwbzG46wYatETMv2M0BfPW6UsqYWcfRBqWzZL2
         HBSfN2KhMmfUA6W/rnTblSV4P+5BzFKIgpupBqfpzi+C3JIo9AEfIvaUQpftktrgqPEe
         blHtdLJqUE1DynRC4sy0BgofpPpcAJ+WpLzjCwjP775QSQkMnOy2VhgIolvhIuurl+3H
         oBOQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b="Ejf/7iUC";
       spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=earonesty@gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com. [2a00:1450:4864:20::633])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-58b011108e3si63351e87.2.2025.10.02.16.40.00
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 02 Oct 2025 16:40:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) client-ip=2a00:1450:4864:20::633;
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-afcb78ead12so310675166b.1
        for <bitcoindev@googlegroups.com>; Thu, 02 Oct 2025 16:40:00 -0700 (PDT)
X-Gm-Gg: ASbGncvf+z+MeFkOULQaMnKEjhZb6k6fWOELxb5UmNVusr5v/VaL0+PY4gfE4L9tClB
	NS0rlL6A86uIw5Px49JMIskRMxm5NCe/WC7X5qWg/cY6eaac24pAvjTYjxHz5zOtfjEaIIc/iId
	/k7Ws6s5H14AUe8B1EtViGtG6LQUnZRrj1k1d6BUHOMAyqiJqejafECFm7uIFG/FCtKVfsbEaYg
	94eeCp97PtdM8BbLaS+TwTVRu4kbZYJLtonLBcnj4nqJCw+4Gar5igJQnZSrT3JdlOQCb00I1B7
	KBrkSFEI2Ot31J1zoAaIq5xSuQ==
X-Received: by 2002:a17:907:2d91:b0:b45:8370:eef6 with SMTP id
 a640c23a62f3a-b49c23457acmr140287666b.19.1759448400068; Thu, 02 Oct 2025
 16:40:00 -0700 (PDT)
MIME-Version: 1.0
References: <GDC-d847c0e8-4e35-40c5-87e7-2ab89e13ea09@google.com>
 <CAJowKgLE4kb7qT1NxXrmEssr8+fQGd-=7=m-BAsjePoti8TRRg@mail.gmail.com> <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com>
In-Reply-To: <yWSgWCkIJcRS4SRwKDLGs3M3Ui-bDH-sCOUqwxXhWo8Y4RSt-UcCMKs3vd6le6l3S3j8yVt3Tqylyhq9MhgTVLpf0D5wtkCEXoJhbEyl-B0=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 2 Oct 2025 16:39:51 -0700
X-Gm-Features: AS18NWCJUE_iXOihAirWU4SsnQvN5gMWR5kTqCtb5iw-SSWFsBSMezKCZBH-j-E
Message-ID: <CAJowKg+et-84+BvkwE=Kjkms-gX-2peT+jvDJSXbHT-MLXan7w@mail.gmail.com>
Subject: Re: [bitcoindev] OP_CHECKUTXOSETHASH idea
To: moonsettler <moonsettler@protonmail.com>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000e3062f0640358095"
X-Original-Sender: erik@q32.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@q32-com.20230601.gappssmtp.com header.s=20230601
 header.b="Ejf/7iUC";       spf=pass (google.com: domain of
 earonesty@gmail.com designates 2a00:1450:4864:20::633 as permitted sender)
 smtp.mailfrom=earonesty@gmail.com;       dara=pass header.i=@googlegroups.com
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.7 (/)

--000000000000e3062f0640358095
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree, this doesn=E2=80=99t belong in general script where it could creat=
e
mempool weirdness; also the DoS surface is real if checkpoints can be
demanded arbitrarily.

Verification isn=E2=80=99t nearly as heavy as you suggest though. Every val=
idating
node already maintains the UTXO set; computing the salted hash once per
epoch is basically a linear scan with caching.  Incremental hashing
techniques can make it even faster.

To reduce attack surface: commitment in the coinbase only, at most once per
difficulty epoch. No mempool footprint, no risk of pinning attacks, and no
repeat scanning.  Nodes just compute and cache the root when they process
the epoch=E2=80=99s first block, then check a 32-byte value at the epoch=E2=
=80=99s end.
Producing that root is still expensive enough to require real incentives
(sponsor still has to pay for it, and that's OK) - checking it is trivial.

Voluntary and expensive to make, cheap to verify, consensus-enforced if
present but never mandatory. Miners and sponsors decide if it=E2=80=99s wor=
th
burning the cycles, nodes get a safe fast-sync path.

The key ingredient is sponsor-paid-work.  This thing disappears if nobody
wants to pay for it or mine it.

On Thu, Oct 2, 2025 at 3:40=E2=80=AFPM moonsettler <moonsettler@protonmail.=
com>
wrote:

> Hi Erik,
>
> Since it is costly for nodes to compute, this is a bit of a DOS vector. I
> would suggest to limit UTXO set commitments to every 2016 blocks (either
> the first or the last block of a difficult adjustment epoch).
>
> If it checks the UTXO set commitment of a previous block, it will not
> interfere with mining, for example always commit to the initial state of
> the difficult adjustment epoch at the end of the epoch. The hash can be
> calculated well in advance. It also would be the same in every check, so
> it's not possible to use it for denial of service.
>
> It's a bit interesting that the script can not be fully validated before
> it hits an actual block. It also allows for submitting a transaction into
> the mempool that might be invalid to mine, that needs additional steps fo=
r
> eviction. Wonder if this allows for weird new pinning attacks for free?
>
> Overall I have low confidence that this belongs in script instead of the
> coinbase transaction structure via a more specific soft fork.
>
> BR,
> moonsettler
>
> On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty <erik@q32.com>
> wrote:
>
> > A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`,
> allowing miners to optionally commit a deterministic hash of the current
> UTXO set into a block. If present, all nodes must verify its correctness =
or
> reject the block; if absent, the block is still valid. Old nodes treat th=
e
> opcode as unspendable, so backward compatibility is preserved.
> > Because computing the full UTXO root is costly, this makes each
> checkpoint intentionally expensive to produce, ensuring that miners will
> only include them when compensated with sufficient fees. Additionally, it
> could be limited to one per block.
> >
> > The result is a voluntary, self-limiting, incentive-aligned, fee-driven
> system where checkpoints are cheaply consensus-enforced when included but
> never mandatory.
> >
> > Most nodes could operate on a rolling history validated by occasional,
> high-value commitments, while archival nodes remain free to preserve the
> full chain. This reduces the burden of initial sync and resource use
> without sacrificing Bitcoin=E2=80=99s security model, since any invalid c=
heckpoint
> would invalidate its block.
> >
> > In practice, the chain becomes more efficient for everyday use while th=
e
> historical record remains intact for those willing to bear the expense of
> maintaining it.
> >
> >
> >
> > --
> > 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/CAJowKgLE4kb7qT1NxXrmEssr8%2=
BfQGd-%3D7%3Dm-BAsjePoti8TRRg%40mail.gmail.com
> .
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-MLXan7w%40mail.gmail.co=
m.

--000000000000e3062f0640358095
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>I agree, this doesn=E2=80=99t belong in general script =
where it could create mempool weirdness; also the DoS surface is real if ch=
eckpoints can be demanded arbitrarily.=C2=A0 <br><br>Verification isn=E2=80=
=99t nearly as heavy as you suggest though. Every validating node already m=
aintains the UTXO set; computing the salted hash once per epoch is basicall=
y a linear scan with caching.=C2=A0 Incremental hashing techniques can make=
 it even faster.</p>
<p>To reduce attack surface: commitment in the coinbase only, at most once =
per difficulty epoch. No mempool footprint, no risk of pinning attacks, and=
 no repeat scanning.=C2=A0 Nodes just compute and cache the root when they =
process the epoch=E2=80=99s first block, then check a 32-byte value at the =
epoch=E2=80=99s end. Producing that root is still expensive enough to requi=
re real incentives (sponsor still has to pay for it, and that&#39;s OK) - c=
hecking it is trivial.</p>
<p>Voluntary and expensive to make, cheap to verify, consensus-enforced if =
present but never mandatory. Miners and sponsors decide if it=E2=80=99s wor=
th burning the cycles, nodes get a safe fast-sync path.<br><br>The key ingr=
edient is sponsor-paid-work.=C2=A0 This thing disappears if nobody wants to=
 pay for it or mine it.</p></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 2, 2025 at 3:4=
0=E2=80=AFPM moonsettler &lt;<a href=3D"mailto:moonsettler@protonmail.com">=
moonsettler@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Hi Erik,<br>
<br>
Since it is costly for nodes to compute, this is a bit of a DOS vector. I w=
ould suggest to limit UTXO set commitments to every 2016 blocks (either the=
 first or the last block of a difficult adjustment epoch).<br>
<br>
If it checks the UTXO set commitment of a previous block, it will not inter=
fere with mining, for example always commit to the initial state of the dif=
ficult adjustment epoch at the end of the epoch. The hash can be calculated=
 well in advance. It also would be the same in every check, so it&#39;s not=
 possible to use it for denial of service.<br>
<br>
It&#39;s a bit interesting that the script can not be fully validated befor=
e it hits an actual block. It also allows for submitting a transaction into=
 the mempool that might be invalid to mine, that needs additional steps for=
 eviction. Wonder if this allows for weird new pinning attacks for free?<br=
>
<br>
Overall I have low confidence that this belongs in script instead of the co=
inbase transaction structure via a more specific soft fork.<br>
<br>
BR,<br>
moonsettler<br>
<br>
On Tuesday, September 30th, 2025 at 2:11 AM, Erik Aronesty &lt;<a href=3D"m=
ailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
<br>
&gt; A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allow=
ing miners to optionally commit a deterministic hash of the current UTXO se=
t into a block. If present, all nodes must verify its correctness or reject=
 the block; if absent, the block is still valid. Old nodes treat the opcode=
 as unspendable, so backward compatibility is preserved.<br>
&gt; Because computing the full UTXO root is costly, this makes each checkp=
oint intentionally expensive to produce, ensuring that miners will only inc=
lude them when compensated with sufficient fees. Additionally, it could be =
limited to one per block.<br>
&gt; <br>
&gt; The result is a voluntary, self-limiting, incentive-aligned, fee-drive=
n system where checkpoints are cheaply consensus-enforced when included but=
 never mandatory.<br>
&gt; <br>
&gt; Most nodes could operate on a rolling history validated by occasional,=
 high-value commitments, while archival nodes remain free to preserve the f=
ull chain. This reduces the burden of initial sync and resource use without=
 sacrificing Bitcoin=E2=80=99s security model, since any invalid checkpoint=
 would invalidate its block.<br>
&gt; <br>
&gt; In practice, the chain becomes more efficient for everyday use while t=
he historical record remains intact for those willing to bear the expense o=
f maintaining it.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePoti8TRRg%4=
0mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
.com/d/msgid/bitcoindev/CAJowKgLE4kb7qT1NxXrmEssr8%2BfQGd-%3D7%3Dm-BAsjePot=
i8TRRg%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-MLXan7w%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/bitcoindev/CAJowKg%2Bet-84%2BBvkwE%3DKjkms-gX-2peT%2BjvDJSXbHT-=
MLXan7w%40mail.gmail.com</a>.<br />

--000000000000e3062f0640358095--