From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 12 May 2026 09:02:53 -0700 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 1wMpZM-0007aM-NW for bitcoindev@gnusha.org; Tue, 12 May 2026 09:02:53 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43013bffd49sf14453383fac.0 for ; Tue, 12 May 2026 09:02:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778601766; cv=pass; d=google.com; s=arc-20240605; b=W3wCYXvliiyUTRmTs6/oOhIJzIzBHKH/jT/PsnSJfg4THod9HDQ0H1fr/aLChFayRQ ywWCIQhPFvHZsCTlhWQsExzBF9diddiPRDuMhIa9r6pq1mqrKSf8ISIFzVzkGwoR4ZqH 2wYnRuPYwg1gu5GaH3KsXsFROY10+RojVwYRHYkCn2LvBj4u/T5vg8oIMYoH70EEX6Yo 7SvE/QTIdSLP34dPbHlZida9b12ZxR9qZhtIqqMBRvJElC/KsZm1Oi9IpBN6yUAKKJBx HCoSuU070V8hnk8g/Iy6/YJ+tH1uE6qJdGKoY0AvTgSqiydc2PAXPMxOFj2PRY1Wm/+4 gIiw== 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:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:sender:dkim-signature; bh=eaaRHaAdyKxSwc+h6P4/fMh3wy+32jEG4ype7/vGwDc=; fh=UTrU2n/0wnIFfeR3oui2Gt3c2jPd94hT4k9kir3m3nk=; b=LIcNA1Zr2YtnhvLUOvuwzP4A/FVP6BBEC/uoFJLdpXIoxEbS9K7mkhKsS13tIEvEE1 9iQu+fcJlDG27fDnhx66rSNOPp3jRkhd6SXjHb8JDw+3+VrgVBqJJ9+coPPs4T2fXyqt js4DUJn4Pg79wkNsJFvQ91EL9lHm6Qlr1Y/zsZVKu1JHzvUd5cSHt/QMhNkgrJyLpS+l VN5AoyGm+e2oyxK6EquCAkm9hQVFGCwQvboAVpXNc980UM626mONVWk2hqRg6BDjHA2q ajuLHf7IqcKEYIuR6heL+f7rFGoSPFPnDZR5H7M0nDzQFKOoMUEzt9K7LgdFB1UH3rQd RFOQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=ZMZ9Vkb3; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=eric@voskuil.org; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778601766; x=1779206566; 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:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=eaaRHaAdyKxSwc+h6P4/fMh3wy+32jEG4ype7/vGwDc=; b=WBDgYa41p4JXBiM87VOUNQ5iHEWwuR+xKP3Tz/Yzqjemc6+K1MFTRSiwKCCXQweV0k O9GZFwgSrRgj7ul1vROQkDoa0EtaMkYusWpVFyFn0GuAJbxJCRmhKXR9e2BMKqVVzdaX 5aymYllp8klQWeQqtQiLBwmdj9YG2OW1r/HC3N7uaXu4RgGt5V0/JHs0Ic8cHbRaTMH1 tSwlc2+Wazrqx/RzdIslAnnaQTnKeZnplYXsW40XraTeSEBmTlku/dgxaIeKoG5oxfBy nDcEPjp4HRvSDGHNfL836z1wRZ7ySHUAJ/Nsl/mcHy2xfseAz3RWvt3VC0CMFqGoYqqz r9hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778601766; x=1779206566; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=eaaRHaAdyKxSwc+h6P4/fMh3wy+32jEG4ype7/vGwDc=; b=VQTOtawk+t/JF03/y33u2ZW8qp97SrEnCg2CI6dB1COBofelSQ/64KjgqJmtGNUU0a lE4cVBhEBtTe6BMQ/tgsOOfUzHKPbY0cut5RhptTRS5eyOYn2plkYFcJo7BlUZfc/WBw 7c2MNI9PlTO0gukGTVmZRPdFvH7gboCsr8rUL5Q6GhTuWfqW9Z+hOHsSmPm0UFN2X1K4 enYdONN2QTn4VECc6XAULZr7C0nNkMbQ91gmGv4MdE4QPXDg5AmqMuWj5XLexV/9fDxg LJJodImAIdLm+qaJKTrdXphpVicFgFWsJe7PietMnxUvlRqQ8hZPbDWz0FOsYpJfqKmK KTAw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9is2072P7PQ0m20XazjPLmQaoMSTRCpeRpZ2SQykXE8wOMpMb0Fh50+vdhzsfJe9ayDq4sUHkfyihB@gnusha.org X-Gm-Message-State: AOJu0Yy1ckLLxs83yt47+MEFhEiKWoGPypOeXcvQyUQGgL36G6mU1QKg nsYZ4dppYLY4QT/PqEY2ICqiJgimOHiisDBPpt/MYgOllcLDYGIMFPjw X-Received: by 2002:a05:6870:d609:b0:3e8:9b72:5cda with SMTP id 586e51a60fabf-4399b5dbfb6mr2319562fac.11.1778601766138; Tue, 12 May 2026 09:02:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOkfYS09SqEXqxumuLhSOhGCYhHuKXquz2anyzRuJQnEQ==" Received: by 2002:a05:6871:653:b0:430:b76:607f with SMTP id 586e51a60fabf-4399a5689bbls515355fac.2.-pod-prod-00-us-canary; Tue, 12 May 2026 09:02:38 -0700 (PDT) X-Received: by 2002:a05:6808:c145:b0:479:d674:dce9 with SMTP id 5614622812f47-48293b81fbdmr2700371b6e.1.1778601758755; Tue, 12 May 2026 09:02:38 -0700 (PDT) Received: by 2002:a05:620a:bca:b0:906:4363:e55d with SMTP id af79cd13be357-90cf3e0dad0ms85a; Tue, 12 May 2026 08:56:36 -0700 (PDT) X-Received: by 2002:a05:620a:361d:b0:8ca:3715:eea5 with SMTP id af79cd13be357-90cb6dfdb78mr461897685a.14.1778601396036; Tue, 12 May 2026 08:56:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778601396; cv=none; d=google.com; s=arc-20240605; b=JZct/mB8e3J2tAWorK/6MO+yrKJHSQNIdrRrv88LmqMd/nYACT2aYtHWYPixmzcZsx YuINpk7csJ15X6EGiO4xpEHXAHviVoNDFssvDfI9wb4jxyF0vdpgg19Cvks+fgoiW6+j 8UZl2ZGytjDGXduvob8eF/D55VHO+Nw0s1W+rqZIE7stLAK3RyqrXCP2fDaC9blkJa26 dC3N3CreMuLa+JrEBnqDNxxQlxz46VMSKxwIut69itGfO3EIBlm9leTrPaXTVebOQoD/ sqvm9ZfU7Cv+wuPW8jEvStSN8FB5HPUWzcnjLww3K2jDoiXqhTS/NShNbQ2yS8/D5mCy vblg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:dkim-signature; bh=mak9CZ3XZXP7UMNAa43Y9BRcz7gfqxHtART609lrMWI=; fh=WtJyVcdUCpKEazA4x1I1hycqepaB0Hy6xq5eJX+MovQ=; b=g4miIj7NfQghzsTOoDCc4XKDxq+6NbcJrjB/wkESuVLVOb30Zwb4rxMzyQfaKmoWgb Elhp9e3wBg3hv+pyZsvixYVGeiR8xTkvCtp9hFq+r9x7nVsmpsEONnhOurxju36q86Au Dmf+XGyQcOxMuFeBi8y2j/JIWyAYYUsb9YX3hBHWDvfZ8u7Z884PpN7rOz5s03r4//ZI zvD2w4w0usqXIoKckDGoKwLN7ACnPNeYr98wYyDhBKvLgYjtuj8jCLB8jKtnxVhDTjR7 m/v8Mi6hlu/nCrpd2Ti84CJ6t0ph/GrQwIbtRLlWtgrwEcHnrWRBRtFvD/N2jg02sN9e jLuw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=ZMZ9Vkb3; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=eric@voskuil.org; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com. [2607:f8b0:4864:20::f2f]) by gmr-mx.google.com with ESMTPS id af79cd13be357-907bddebb34si45138785a.3.2026.05.12.08.56.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2026 08:56:35 -0700 (PDT) Received-SPF: pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f2f as permitted sender) client-ip=2607:f8b0:4864:20::f2f; Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-8b5cda2dab9so54969996d6.0 for ; Tue, 12 May 2026 08:56:35 -0700 (PDT) X-Gm-Gg: Acq92OE9efXkFhEdUzbi5rlNYkOVvGchUfUBjoP/o+O7cGduxc6VyAUBweiykZ+3T97 tXOO8exG0U85E4/mL8eoDC/NRw4CqAhsed3P3XB4V0tnhIeAOemeYS+Ngc1b9MMzhMffDG+wPRi beH54vje1S6TF3fo3qP5ZF58Vlf2Jo651dnJ8HphB2+ykNjZb3KZTawIC4nXlHI8vvsT0UBkOu0 6XcjSUwtrYKkWAlaVvYCwIHWFHiBysdZA7nVNOEesAIz0KN3mQpYEvMzeLNGXVBkx46++D33Od8 hl4hrsMFygwhR2hnseWVI2InvW3xJ9j3ffFp1ZGf2sWP7JsuSfnQBieICSp49YZwiXLByzCvtVs lSRNxasLm60iRio/3wa27HvZDCWXaUjC22o8EOOv9Pxb8MaOxWyQuPUNJsVsS/AwvAqTfwAHmu9 U5ESogjAdFo9sg6QPMq2Nppmm8njyBOw== X-Received: by 2002:a05:622a:110:b0:50f:b181:6ae7 with SMTP id d75a77b69052e-514cef74db9mr51762831cf.17.1778601394914; Tue, 12 May 2026 08:56:34 -0700 (PDT) Received: from ERICDESKTOP ([216.212.108.156]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5148e6754b2sm121145051cf.10.2026.05.12.08.56.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2026 08:56:34 -0700 (PDT) From: To: "'Fabian'" Cc: "'Bitcoin Development Mailing List'" References: <19616822-8a03-4de1-99be-72d50479208fn@googlegroups.com> In-Reply-To: Subject: RE: [bitcoindev] Re: [BIP Draft] P2P UTXO Set Sharing Date: Tue, 12 May 2026 11:56:33 -0400 Message-ID: <02c201dce227$e808e050$b81aa0f0$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE9V3UU3txRcB+TPknCl7kBT2x4HgI+SqEvAnGwGX23JBGeUA== Content-Language: en-us X-Original-Sender: eric@voskuil.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=ZMZ9Vkb3; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=eric@voskuil.org; 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.8 (/) Hi Fabain, Thanks for the reply. Comments inline. > AssumeUTXO is a UX improvement for those interested in running a fully > validating node. The option to get started in > a very limited amount of time even under significant hardware constraints > can motivate users to choose a full node over an SPV client if startup ti= me is > relevant for their decision. It's not at all clear to me how this is a UX improvement. Get started doing= what? > And at some point of hardware constraints it definitely is, I think. This implies that that hardware constraints are somehow overcome by this, w= hich is not the case. > In addition, it is a much easier decision for users to do IBD > with assumevalid=3D0 as they are not required to wait for the completion = of > background IBD to take the next steps in their setup. These aren't limitations inherent in protocol. The implementation details o= f a given node aren't relevant. > Also, this proposal only improves the sourcing of the UTXO set. Currently= this > needs to happen through some third party source and loaded into the node > manually which comes with it=E2=80=99s own set of potential risks (privac= y, malware), > being able to rely on the P2P network as a secure source is preferable to= that. This is again an implementation detail of a specific node. Neither assumeva= lid nor assumeutxo are protocol. These are trust-based features of a specif= ic node implementation (not a "secure source"). The distribution of trusted= blobs was a known design flaw of assumeutxo. But it has long been suggeste= d that these could be just distributed via the p2p network. The similar bip= 64 was in 2014. Predictably the former is now being used to justify the lat= ter. But of course this presents another problem, that of the cost of valid= ating them, requiring full validation of the chain. So this inevitably lead= s to miner commitments. > I think your main critique boils down to =E2=80=9Cthis is a slippery slop= e=E2=80=9D aside from > your critique of assumeutxo... I can not refute > critique of something that is not part of this proposal except for pointi= ng out > that what you are insinuating is not something I am working on or plan on > working on... Even if for some reason you cannot comment, I and others can. The above sli= de from trusted utxo downloads to p2p distribution of them makes the point = already. Ad-hoc downloads was obviously going to lead to the p2p distributi= on proposal. And that proposal (here) is obviously going to lead to a new p= roposal for miner commitments to utxo state. This has been discussed as far= back as 2015, and has been implemented in altcoins. It was a primary big-b= locker proposal to resolve the inability to validate larger blocks. It achi= eves this by not validating them, which is of course the critique. Whether = you would support that or not is not the relevant question. > In contrast to some hypothetical dangerous future extension of this > proposal that you are warning about... It is not hypothetical, and it is dangerous. This understanding is at least= 11 years old: >> Full nodes using UTXO set commitments is a change to the bitcoin >> security model. >> >> Currently an attacker with >50% of the network hashrate can rewrite hist= ory. >> >> If full nodes rely on UTXO set commitments such an attacker could create >> an infinite number of bitcoins (as in many times more than the current >> 21 million bitcoin limit). >> >> Before we consider mechanisms for UTXO set commitments, we should >> seriously discuss whether the security model reduction is reasonable. - Patrick Strateman, 2015 https://gnusha.org/pi/bitcoindev/55FC6951.9010704@gmail.com/ > I am convinced that it does have real positive impact on users > today, as I pointed out above. Entirely dismissing these very relevant issues while assuming a "real posit= ive impact" is not sound analysis. I am not aware of any use of a not valid= ated full node. Maybe an untrusted block explorer, but there are plenty of = those available online. Some full nodes do provide full functionality up to= the point of validation, while building the chain (including block explore= rs). This proposal is a bug (p2p trusted distribution) that attempts to fix the = assumeutxo bug (ad-hoc trusted distribution), and the only "fix" to the lat= ter will be miner commitments (soft fork). And there is no material benefit= to any of it. The chain must still be fully validated, and is not usable u= ntil it is. Arguments in favor of this approach are thinly veiled support f= or a rolling utxo commitment scheme, as a "solution" to the lack of scalabl= e implementation. e --=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/= 02c201dce227%24e808e050%24b81aa0f0%24%40voskuil.org.