From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 16 Nov 2025 11:21:29 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vKiJU-0003T5-MX for bitcoindev@gnusha.org; Sun, 16 Nov 2025 11:21:29 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3e88192e178sf967831fac.1 for ; Sun, 16 Nov 2025 11:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763320882; x=1763925682; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=OZrMkPxkqiRfpLcvFTzoXDx0tsQnZydjkcZRoi8YWz4=; b=iNqtMz2RqIMhr8myPDGsep/WpW80cP1SHBu0rYiwm/7N+Q2FnmEqcFIUnAQC6rgHgQ H/uoRSSdWLGkSHPSH7vdXFaJbNpCoPb2pn78/rb2srtojW7smoCB8+zGOfy/vkI3VvHN UWWL2Ttzl46Db66yWY36iaU4uafHmfHAl2HLfhJ5XDYIo09VYmtF2FE9gl45r2HEj5EL DclvjoAUlRZnGNu2JN0T1DKsAbe8IXtbA71vz6uTkHB6hc3upToWifBNW0U1dg7/yv1c oqfLgTBP4VTM9NzcSCyX0ky+VSPgpUae64cVkyenTXT1WGYhNKgv8fNfBcQf/wD+MKxo njNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil.org; s=google; t=1763320882; x=1763925682; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=OZrMkPxkqiRfpLcvFTzoXDx0tsQnZydjkcZRoi8YWz4=; b=iHvmh1WaaFdQeUa0Vmt8lQ/4PeLw1gcA2G13K2gHVqULFzusHvZWsqhj1mVHll+mbp TlmAOY7ktOykm+IHi4HKrVBLJd8s6WroM/AcMea+AHehoQw8PxVRfoGWHzK0ooLp51Yd G5agd3rH1KFNNs+tLAUVdBoAfgG6Fr5HhTH42y4patI5l7FkbdWL9I4/CbSTrjSUWdSt NwAbhEvt7+2E3M11olxTRnjhXQWzMyX4fjSwUHJDLzWDRqReFZV6DT00kq+/OAmlSW5l Ilpwa0yPLkKOlggJxMeDGSeOLw3n7lvoH5ddv+h9GKxcE+aL64pd7t5KZOJ2di7J2eBf EO/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763320882; x=1763925682; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=OZrMkPxkqiRfpLcvFTzoXDx0tsQnZydjkcZRoi8YWz4=; b=D1WXdVTAMoWqtBEluM8NnpS0nvBXJK3s4BF1Vevcpg3zm1Ms03iPS/Qv0oOwFmShqK 1Z/JqPEc1PUoUNqrj+85dS+d8LdqCRinSit1h59CtiPY08Q9eSqqvVjfbu+3E558C2/r wVlBHuVzYl7m4qK7m5jSV4scPn7g+PpP3Xi4ITgvy01JAqZarEVCrsh6J/WSLf5Bh3Qf bMVfxl4CQ4w3hWPF1rrPXhOePEcU3N4F5KVjkGJ7/MVuKynBuUknOdHquHrMUpzVlmKm Ra0nYT/jFdSSMqFtCxuuyHmNxap9y1fakJH7Bsfc2Mnu5W75mTGUgQwcnpLrovA2XunU egdQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVynDXmGz3AlBj/6IElqNND/wrArJpvfavc+fKyMYEFHdhw1dmBHo4pQRKcPreY+cwOLzGWk2m9Hrgr@gnusha.org X-Gm-Message-State: AOJu0YzyaUzf2i6A9HT9Nm6Ezkre8z309sngxIJWG4Hu1NfjylZuU610 Yp9PUWu5JA7NmMSC2KGXqb7Yql3N8J7bLz0ey4Xz02/OBaKFmENRRM7r X-Google-Smtp-Source: AGHT+IHxiizOyMYxz/DYoTzFNZeu00X9PoMnCUaQlWjr8bWQCu3++jWAn6JrgWBujAgV2YwgM4fvCQ== X-Received: by 2002:a05:6871:cc88:b0:3ec:3308:f73 with SMTP id 586e51a60fabf-3ec33084813mr972338fac.42.1763320882304; Sun, 16 Nov 2025 11:21:22 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+b12gixJJCLdOg0fz1y6vBYiilkcIhdegtGl7O/fjN+2Q==" Received: by 2002:a05:6871:6b15:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3e84b349b83ls1811218fac.0.-pod-prod-09-us; Sun, 16 Nov 2025 11:21:16 -0800 (PST) X-Received: by 2002:a05:6808:6706:b0:44f:e1af:21f4 with SMTP id 5614622812f47-450973be299mr4473020b6e.4.1763320876370; Sun, 16 Nov 2025 11:21:16 -0800 (PST) Received: by 2002:a05:690c:6303:b0:785:e55d:2dfd with SMTP id 00721157ae682-78929f9dfd3ms7b3; Sun, 16 Nov 2025 11:11:18 -0800 (PST) X-Received: by 2002:a05:690c:869b:b0:788:f66:7822 with SMTP id 00721157ae682-78929e0d18dmr70519477b3.4.1763320277241; Sun, 16 Nov 2025 11:11:17 -0800 (PST) Date: Sun, 16 Nov 2025 11:11:16 -0800 (PST) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: <76c1b5a1-5b78-4576-981f-4df69aefc9a6n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: OP_CHECKUTXOSETHASH idea MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_380644_659877097.1763320276822" X-Original-Sender: eric@voskuil.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_380644_659877097.1763320276822 Content-Type: multipart/alternative; boundary="----=_Part_380645_742609980.1763320276822" ------=_Part_380645_742609980.1763320276822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Erik, > Most nodes could operate on a rolling history validated by occasional,= =20 high-value commitments, while archival nodes remain free to preserve the=20 full chain. This is an old big-blocker idea, and still a terrible one. It effectively= =20 reduces what we now call validation to majority hash power control. IOW=20 functionally equivalent to SPV. A few actual full nodes (maybe) validating= =20 does not have the implied effect. For a node's validation to matter, the=20 node has to be accepting coin in trade. SPV entirely relies on the=20 presumption that a very large portion of economic activity is actually=20 validated. Very large means enough that majority hash power has a true=20 disincentive to intentionally mine invalid blocks, despite the reward for= =20 doing so (e.g. unlimited inflation). What you are calling "archival nodes"= =20 don't actually "preserve the full chain" for everyone else, because their= =20 effect is limited to their own transactions. Otherwise we are talking about= =20 fraud proofs, which is a conversation that doesn't end well. > Because computing the full UTXO root is costly... It is not, it's getting cheaper every year. e On Monday, September 29, 2025 at 8:11:51=E2=80=AFPM UTC-4 Erik Aronesty wro= te: A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowing= =20 miners to optionally commit a deterministic hash of the current UTXO set=20 into a block. If present, all nodes must verify its correctness or reject= =20 the block; if absent, the block is still valid. Old nodes treat the opcode= =20 as unspendable, so backward compatibility is preserved.=20 Because computing the full UTXO root is costly, this makes each checkpoint= =20 intentionally expensive to produce, ensuring that miners will only include= =20 them when compensated with sufficient fees. Additionally, it could be=20 limited to one per block. The result is a voluntary, self-limiting, incentive-aligned, fee-driven=20 system where checkpoints are cheaply consensus-enforced when included but= =20 never mandatory.=20 Most nodes could operate on a rolling history validated by occasional,=20 high-value commitments, while archival nodes remain free to preserve the=20 full chain. This reduces the burden of initial sync and resource use=20 without sacrificing Bitcoin=E2=80=99s security model, since any invalid che= ckpoint=20 would invalidate its block.=20 In practice, the chain becomes more efficient for everyday use while the=20 historical record remains intact for those willing to bear the expense of= =20 maintaining it. --=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/= 76c1b5a1-5b78-4576-981f-4df69aefc9a6n%40googlegroups.com. ------=_Part_380645_742609980.1763320276822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Erik,

>=C2=A0 Most nodes could operate on a rolling history validated by occasional, high= -value commitments, while archival nodes remain free to preserve the full c= hain.

This is an old big-blocker idea, and still a terrible one.= It effectively reduces what we now call validation to majority hash power = control. IOW functionally equivalent to SPV. A few actual full nodes (maybe= ) validating does not have the implied=C2=A0effect. For a node's validation= to matter, the node has to be accepting coin in trade. SPV entirely relies= on the presumption that a very large portion of economic activity is actua= lly validated. Very large means enough that majority hash power has a true = disincentive to intentionally mine invalid blocks, despite the reward for d= oing so (e.g. unlimited inflation). What you are calling "archival nodes" d= on't actually "preserve the full chain" for everyone else, because their ef= fect is limited to their own transactions. Otherwise we are talking about f= raud proofs, which is a conversation that doesn't end well.

>= =C2=A0 Because computing the full UTXO root is costly...

It is n= ot, it's getting cheaper every year.

e

On Monday, September 29, 2025 at 8:11:51=E2=80=AFPM UTC-4 Erik Ar= onesty wrote:
A soft fork could introduce a new opcode, `OP_CHECKUTXOSETHASH`, allowi= ng 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 the opcode = as unspendable, so backward compatibility is preserved.=C2=A0

Because computing the full UTXO root is c= ostly, this makes each checkpoint intentionally expensive to produce, ensur= ing that miners will only include them when compensated with sufficient fee= s. 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 consensu= s-enforced when included but never mandatory.=C2=A0
=
Most nodes could operate on a rolling history= validated by occasional, high-value commitments, while archival nodes rema= in free to preserve the full chain. This reduces the burden of initial sync= and resource use without sacrificing Bitcoin=E2=80=99s security model, sin= ce any invalid checkpoint would invalidate its block.=C2=A0

In practice, the chain becomes more= efficient for everyday use while the 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/76c1b5a1-5b78-4576-981f-4df69aefc9a6n%40googlegroups.com.
------=_Part_380645_742609980.1763320276822-- ------=_Part_380644_659877097.1763320276822--