From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Jan 2025 09:36:01 -0800 Received: from mail-qv1-f57.google.com ([209.85.219.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tcpVI-0002la-Rx for bitcoindev@gnusha.org; Tue, 28 Jan 2025 09:36:01 -0800 Received: by mail-qv1-f57.google.com with SMTP id 6a1803df08f44-6d89154adabsf96339496d6.0 for ; Tue, 28 Jan 2025 09:36:00 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1738085755; cv=pass; d=google.com; s=arc-20240605; b=eOcD7X2PsSm6jFzVS1KvWi62VBNYtoquWeRVxBCQ0R+TF0CtlVzIUG/32Rg3BfGIvz GXpXakLkgzTh/eIomHQY7elQ/ZEd47HTMVU0eWMu1U4EKKwHBoUywcfHetYJG+8S1GHK hz6r90kk8wpFTEee0Yd6mgrSYwIDqUifCpKGNjflbfQyjJp6vhNvfUYJLPh3AdDf2byR KLw0cU+/a4t0yJJgnHItlyp7pkBxmpzL6vtU0Cv7ZeNHG3uKcMBEM7MIPZcKSF2U3HDu pjeFsyaemMDLiJAYC7xu5DH0WGqguW/OCvTdCulp14KZqaRqtGUj+Ahnz7biPd97Nb52 dvMw== 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:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=Y6vc+sXo2wAmLyoIoBtARbF9FBDKhQ9PDzx36lM8VAU=; fh=0H5Y1/QKFSF505NQ7xFVGuLjGcd2NjyxaVoPGDWNAAU=; b=bp0cZx33oLBGedjS63fKG4V8I23yiDPseB4fEM9L2H+EeuM3UlUADYgwy9qCAXNTEY mWKAnim3ytsRGXP99tHXn6FPbFSqVv85p8UhHzae+xh1kXnCb8u05Fi3tGnqIOui9fsz tfcmuZoSo3gGj1djbqe+0ifkoErWfPYEagIg29OKZWgCa8U8Vt8A9+nXic6060+tvSPe ZCJj3lbJi0Zuzy19K9hboVqstH3MrsFNx4+8jzB1o3ZVxVmkDSe9Liivig8TOj4iGtB+ bRQFe5APb8D+acVn2NcdwzuS3CcUml6CbDWkjTS/ePsClRMWTCfsFhsPQjAp6W7uCK2L ElGQ==; 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="cZ/1kx4b"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 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=1738085755; x=1738690555; 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:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Y6vc+sXo2wAmLyoIoBtARbF9FBDKhQ9PDzx36lM8VAU=; b=L1X/YuyLLgSQOIh9QnWBKNriqmX1jJhOv0SRwLGAUWSy9+x+J5gGhnI4MGajaeSTX9 SR7Fwd0EUGIuvnUHZjcFRV1mP1fSznJphLiR2Nt9zalUY7MNUbmRFWXhsOOIDjbdOO9P LYxy2e1cdKU4/xc/MKGg9I6F9m74S+IHz/vmkDSjrTEtmpXgzjH0mSJS4ZEct6sB4I/O 0WKVJ5Stib3Zon4cxmkerNNaakaFQvXrBE6fYW6qmtbOJHX6o2V1h5RqVC+bkG2q0gpR 0HDVJYRbJLqaYXvwMHNga+OMw/P0m+CRW4PGVyISn2F0DwfmqanC9ufJdPN/yk5eUDBr 7F3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738085755; x=1738690555; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=Y6vc+sXo2wAmLyoIoBtARbF9FBDKhQ9PDzx36lM8VAU=; b=w0GHDr1fTxsfHu2rQcx7j6kKS2OUrxc/phOpq3xXUhU52ZVqND7EMaS93nuKIL4anA 8DMV6kz4OM4XOPtuvgAxj3C5Jbh0QZRKFOtmMH1dSazJgvYEpcVBwKxYFwRBMG2sZNk+ +iUelrKzF+DA6F5UE6UB12NT0JApLkRELVmGiCFKC+JKmY6ldxDf63XRBAXE+I+9dm5p JAEv7ASOnRophvlX3O+nMlGG3yuBI31gIUB6kX5aZAR6JYXW8dw3d1Fq7QmkVQeVgcot 1av43KdP4T0Wr0g00V8XPjdsQ9iA76KGYUHtLd0hvKnF07qHosM9Q+p/mkJ+5epRjymw lJvQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW8/kEXObrmS3vSL/G/CRmTbYKJmrfq2EaaC961o7/J/1X2C4KPtSsQP9Uy/ph6e5u5WPhWAd5R5tc7@gnusha.org X-Gm-Message-State: AOJu0Yx6lz32vRF3a/U0X5dyXIl4DvnwjWpffrAveuJb1VykulpT0hLd pZUPdzkqqW7zJYizYzzPJuUskcr0OA+wHKSxJgue2UpqAUo2X3gD X-Google-Smtp-Source: AGHT+IGeNshT0j21s9yTLYbovYXzPxlJu0CgfUM4FeJEQu/p9MzxkQxiJzCuBbotzMuyMkUkei4Yog== X-Received: by 2002:a05:6214:f26:b0:6d8:ad28:adbf with SMTP id 6a1803df08f44-6e243bfaa0fmr351096d6.20.1738085753227; Tue, 28 Jan 2025 09:35:53 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ad4:4990:0:b0:6d4:18b4:dc77 with SMTP id 6a1803df08f44-6e1fa228f7cls7468066d6.0.-pod-prod-09-us; Tue, 28 Jan 2025 09:35:50 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXA0pqh60szGH+ds33+rffRbR2PRXrETDMFvJhHK7OlkanILuGiZx4Rk+y2yA2Ej2kSL8dXMHMIWAKs@googlegroups.com X-Received: by 2002:a05:620a:1902:b0:7b1:51df:117f with SMTP id af79cd13be357-7be6325c411mr7919119285a.56.1738085750192; Tue, 28 Jan 2025 09:35:50 -0800 (PST) Received: by 2002:a05:620a:41:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7bff5151a18ms85a; Tue, 28 Jan 2025 09:34:59 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWgGeagVRCT+H/32AArp1+mWmlGVm+AkfpsSpfylcYwF3yTFqyM4IBmXmgIF0CsspTcmmCo6SeC04l6@googlegroups.com X-Received: by 2002:ac2:41d7:0:b0:542:62e6:4517 with SMTP id 2adb3069b0e04-5439c2289d6mr12104464e87.12.1738085694730; Tue, 28 Jan 2025 09:34:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1738085694; cv=none; d=google.com; s=arc-20240605; b=cFBhM2zBasFE1XOOTGu493O95E9Hl++GXroVPNWrXrtzN6z/d009dQvkYSebvClvHi dug23NPMhIHRwR+7sjG587CK4ZuFknSH1wMgij/TJXRj8lVdEys0yWuBKcbMuK25EM1s fvHQlAsfSXVUmIs0mBqVLrST8J/Z44xqlqtDew84noF+AoSnsVTg4oKo6cK7tvXeED/w N8DkaAT4e11bt5Y1vGmlY2asx8pH62GwfhJ7NL17vLMmnzEQLiNThHFD38PKNqEufFTH nJBwL1VY+nUjyWEZPZQ6mucGJeV2BmMATt6ok9vjvNLNDguKf3RlAsAaOLLJwyQMBwsp kRKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=fe1Y8hX5wNltjfo55y32lbJ4MExYm5CIYb1dmXn64rE=; fh=YQxaNPe1oCeU2DkaT20Q3NvY5ntnqbgWaZUtVoARYCk=; b=H/QVj9T1bPz8qaLYQzG03tlhxq4gOxmdlCsh2c/WQ3B1QqYMggUE6QWc/RV1q032dL KNuYbTgcu3fYryf7c61OCWc8BWU0HHORkr2MvxSbT+DEUw0GWoXNB+mv2osP38RUMzYR qcV//Ycaw9FQD7WGg2G4I4juKaTvuOUN6SAPYDm0DrEkbI9t//kFX8nk3fa5ZBPN3coV UIrrXWBLHvLckpmEARIjYO8IHiD+TvKxGoAjt2GKW+tf9stbq6w7LaCm5vv1468MzNQs BcOKwdII4HkBrJ7T5v6TbQL/1yw+pS1849l276CWgIV4SSlFgg/uqEtyb70pW03C3nM8 D5Hw==; 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="cZ/1kx4b"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com. [2a00:1450:4864:20::629]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-543c82228c5si299770e87.1.2025.01.28.09.34.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2025 09:34:54 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) client-ip=2a00:1450:4864:20::629; Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-aab6fa3e20eso999872166b.2 for ; Tue, 28 Jan 2025 09:34:54 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWNQMJ4t0jx1AjiItOo08c5WpDiMA3Y3Qy1GCLHlDtE0ETQazzG1eL12dPeY0lDELXByQlh7HqKPHnI@googlegroups.com X-Gm-Gg: ASbGncuFaQ0wP1kGU2P2u/yRrGZ2ckHlRhkwYZzoG6jImwcvNVAMh0CqSiAxTS4f06W InXrUdeZ4sK57l1sTS0e6pzMU4uPYNqmtXmengAGNarZEgNAEcuvoc/NNTaUEqnRfD+Pj9Q2m4I JRfupbpuAd9cAlGYqQPKEQbO9l3CvVQNgyiNE= X-Received: by 2002:a17:907:934a:b0:aa6:9624:78fd with SMTP id a640c23a62f3a-ab38b4c6436mr4348127366b.48.1738085694171; Tue, 28 Jan 2025 09:34:54 -0800 (PST) MIME-Version: 1.0 References: <128AF3BD-F034-46AB-B5BD-E00B405CB854@voskuil.org> In-Reply-To: <128AF3BD-F034-46AB-B5BD-E00B405CB854@voskuil.org> From: Erik Aronesty Date: Tue, 28 Jan 2025 09:34:45 -0800 X-Gm-Features: AWEUYZnhUlgrGwx_fiUHR2I4TQvqi7nDq7xiKdG6yGGRbH9MUOpKhSakxfQ-Bbw Message-ID: Subject: Re: [bitcoindev] UTXO checkpoint transactions To: Eric Voskuil , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="00000000000063f2fe062cc79c89" 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="cZ/1kx4b"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --00000000000063f2fe062cc79c89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable correct, it's an "all full node vaidates" and not "trust miners only" the intention was to *reduce* the assumption of validity hacks that i agree, are a problem spv should definitely be enough for mobile clients interested solely in their own chain of wallet addresses On Tue, Jan 28, 2025 at 9:11=E2=80=AFAM Eric Voskuil wro= te: > More age doesn=E2=80=99t make it more valid. If you can=E2=80=99t answer = the same > questions that SPV can answer then use SPV. Did you mean the reverse? > > This constant creep toward non-validating bitcoin is troublesome, and > largely driven by poor software performance. We have SPV (without any > chance of fraud proofs becoming useful), =E2=80=9Cassume valid=E2=80=9D, = and now =E2=80=9Cassume > utxo=E2=80=9D, and people are working toward what amounts to =E2=80=9Cass= ume utreexo=E2=80=9D. This > cacaphony of trust-me-bro services that are drowning out individual > validation. > > That aside I cannot see utxo commitments as being beneficial unless they > are validated by full nodes (and how else would miners validate them?). > That still reduces to SPV security, since the wallet couldn=E2=80=99t val= idate it, > but at least it=E2=80=99s not adding a layer of trust that miners alone w= ill > validate it. If you want to ensure it=E2=80=99s valid then it=E2=80=99s a= soft fork. > > e > > On Jan 28, 2025, at 11:52, Erik Aronesty wrote: > > =EF=BB=BF > It seems that a sufficiently aged one would be useful in situations where > you are not able to answer the same questions that SPV can answer > > On Mon, Jan 27, 2025, 10:42=E2=80=AFPM Eric Voskuil wr= ote: > >> Hi Erik, >> >> Miners committing to a checkpoint does not make the checkpoint valid. Th= e >> only way one would know it=E2=80=99s valid is by validating the chain up= to that >> point. >> >> Given that it implies one would be trusting hash power for validity ther= e >> is no need for a utxo set. SPV is sufficient. A utxo set is only necessa= ry >> for validation. >> >> e >> >> On Jan 28, 2025, at 01:32, Erik Aronesty wrote: >> >> =EF=BB=BF >> Has it been considered to add a UTXO checkpoint transaction >> >> Here's how it would work >> >> Someone submits a transaction that contains a large fee and a hash of th= e >> UTXO set along with block height as opcode parameter >> >> Miners refuse to include this transaction unless the hash of the UTXO se= t >> matches >> >> Because performing that hash is expensive, it should have an extremely >> high cost factor, equivalent to say a 100KB transaction or something >> >> These checkpoints are explicitly for the purpose of fast-synchronizing >> extremely lightweight nodes. It's reasonable to refuse to use a checkpo= int >> that isn't at least several months old. It should be easy for anyone t= o >> find a sufficiently aged checkpoint and synchronize from that point onwa= rd. >> >> >> Or is this just a solution without a problem? >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAJowKgLC9LdAu2mrQB-yW2Qoa3= jU3BwZyL%2BQT4WW8f257Jkfhw%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/= CAJowKgJypG%2BW8GO%3Dn4g2Rdk2Qm4v6_hEGXA%2BN7meYRJaCEGpwg%40mail.gmail.com. --00000000000063f2fe062cc79c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
correct, it's an "all full node va= idates" and not "trust miners only"

the intenti= on was to *reduce* the assumption of validity hacks that i agree, are a pro= blem

spv should definitely be enough for mobile clients i= nterested solely in their own chain of wallet addresses

On Tue, Jan 28, 2025 at 9:11=E2=80=AFAM Eric Voskuil <= eric@voskuil.org> wrote:
More age doesn=E2=80=99t make it more va= lid. If you can=E2=80=99t answer the same questions that SPV can answer the= n use SPV. Did you mean the reverse?

This constant creep toward non-validating bitcoin is troublesome= , and largely driven by poor software performance. We have SPV (without any= chance of fraud proofs becoming useful), =E2=80=9Cassume valid=E2=80=9D, a= nd now =E2=80=9Cassume utxo=E2=80=9D, and people are working toward what am= ounts to =E2=80=9Cassume utreexo=E2=80=9D. This cacaphony of trust-me-bro s= ervices that are drowning out individual validation.
=
That aside I cannot see utxo commitments as bein= g beneficial unless they are validated by full nodes (and how else would mi= ners validate them?). That still reduces to SPV security, since the wallet = couldn=E2=80=99t validate it, but at least it=E2=80=99s not adding a layer = of trust that miners alone will validate it. If you want to ensure it=E2=80= =99s valid then it=E2=80=99s a soft fork.

<= div dir=3D"ltr">e

On Ja= n 28, 2025, at 11:52, Erik Aronesty <erik@q32.com> wrote:

=EF=BB=BF
It seems th= at a sufficiently aged one would be useful in situations where you are not = able to answer the same questions that SPV can answer

On Mon, Jan 27, 2025= , 10:42=E2=80=AFPM Eric Voskuil <eric@voskuil.org> wrote:
=
Hi Erik,

<= div dir=3D"ltr">Miners committing to a checkpoint does not make the checkpo= int valid. The only way one would know it=E2=80=99s valid is by validating = the chain up to that point.

Given that it implies one would be trusting hash power for validity there= is no need for a utxo set. SPV is sufficient. A utxo set is only necessary= for validation.

e

On Jan 28, 2025, at 01:32, Eri= k Aronesty <erik@q32.com> wrote:

<= blockquote type=3D"cite">
=EF=BB=BF
Has it= been considered to add a UTXO checkpoint transaction=C2=A0

Here's how it would work=C2=A0

Someone submits a transaction that= contains a large fee and a hash of the UTXO set along with block height as= opcode parameter=C2=A0

= Miners refuse to include this transaction unless the hash of the UTXO set m= atches=C2=A0

Because per= forming that hash is expensive, it should have an extremely high cost facto= r, equivalent to say a 100KB transaction or something=C2=A0

These checkpoints are explicitly for = the purpose of fast-synchronizing extremely lightweight nodes.=C2=A0 It'= ;s reasonable to refuse to use a checkpoint that isn't at least several= months old.=C2=A0 =C2=A0It should be easy for anyone to find a sufficientl= y aged checkpoint and synchronize from that point onward.


Or is this ju= st a solution without a problem?






--
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 bitcoindev+unsubscribe@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowK= gLC9LdAu2mrQB-yW2Qoa3jU3BwZyL%2BQT4WW8f257Jkfhw%40mail.gmail.com.

--
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.co= m/d/msgid/bitcoindev/CAJowKgJypG%2BW8GO%3Dn4g2Rdk2Qm4v6_hEGXA%2BN7meYRJaCEG= pwg%40mail.gmail.com.
--00000000000063f2fe062cc79c89--