From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 08:43:34 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHm2H-0000gD-Rz for bitcoindev@gnusha.org; Sat, 08 Nov 2025 08:43:34 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3c98354c16esf1353087fac.2 for ; Sat, 08 Nov 2025 08:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762620208; x=1763225008; 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=5bxy7qzZYAxqyGH1ozQvBZPLkprWdkgLhUez4Ixfb0E=; b=GN3vFFckEtyBPZRj7Ez6heHco9bdRAZBzo4wK1sVyITnaQQamjpza5r5suNKmB++VH BzGE953ULPtPHU17qnaSwgV1jJG07ngdchPBlpe1aNV4bYubhrpBHrlf2p2Nq5IicaAA OrWNxjR8CUol8nrwkVmpd4fSv55zC/BQiVqS2xdBa8EwcguNn2bykCaINrqs26KmzbHg DfYVE3Aab5cRp1fcoSass1+plzHVWD4TEMwg8NsMRQFVu1xLUaApSEA6EfpLSVTTY6W9 YCUDZnvZFG8LYHYBEpxUkA8YKTzV8RiEekn5FxxkMoOj4a52PCkr+CF8Lly5+XaN1UjS I+Mg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762620208; x=1763225008; 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=5bxy7qzZYAxqyGH1ozQvBZPLkprWdkgLhUez4Ixfb0E=; b=Vx9uKMyP7Cy6479Ryqw4E+WJMjMl5JLCvY/o3jQ2RtATQdPpg3lf7uD0wUMV378zQR jeYUKMxuc10hbqGvT+T5ouav1reQFe3Ttoj0jKYrPr3jdbat0xoRZE8O46TkiKFVV4NL vPTeFVs9+kDGiGfobfXMzPcNAeDKe1oMlRVCAlsj2fLRExBBEaUZumGmQZgXW/TFS/pB gNHX1wDktEVi4E18Dy4pvA9h+gbl8YEW4HQ0e6tduitJF26anQzBSl4BvQtim8DJ5bZQ Hw9haw1BdLeX3UJ1inZXD+IJLP7DnaKEsHT/mmSoiSmVONm4KSiQQgGcjJWHa1hZO/rq 2UeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762620208; x=1763225008; 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=5bxy7qzZYAxqyGH1ozQvBZPLkprWdkgLhUez4Ixfb0E=; b=vIjpSiRmlFboSpSwQ8nGfFsORvi82AzZ6HuJRIvWXIhzvA3FrekJsm2WijDMy/kWii pi7p8zXU1E/RZM9oGN9zpWY5vIhrLSdhWFgXnW1pbVQwoVIM+SflH62KC7JXVzo5KHmo aSj/RK9CVeIzvEWkhkzI9IMqRsjjzkSiCuAKrgT6i7L4BSB75pn37+vUvwbPAkVm8LtY FrHWTPOCh6HmrtT+YzobzFXx5VStei4neA37sBW6AZA9CcIfkIdKl+XusbNJnEA3cKDM KnK9kGa2KxTkNG1LDOsJTKr14pJyJdYHyDYqGWyyjjgADQjTUDCiSBWr6WFnRTRX04+O 0Aeg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV3VAC+eu1ScBzGoenTFruXQeZf99kH8XD9Jl2r9uyj0AIU746lyCa88jKKzsieqSq13+MGFdCGbYj7@gnusha.org X-Gm-Message-State: AOJu0YxvwKemU/rbtSIhRqy6uGxsK6oUFfX609RO7DBDYDSVQTWTnoSA PD12kmjMSwnLixWCW8BQi4hFdlMvPohcuKpohdoupw6ofCw6gMDJKx5V X-Google-Smtp-Source: AGHT+IE1cuZfOXjwLr/nK6DH3b2kIvE0LcKUSHEl+8hG6sRCcGroAJRYVXQDA+bb8cifHtArF6fH/w== X-Received: by 2002:a05:6870:961d:b0:3c9:810d:494b with SMTP id 586e51a60fabf-3e7c255e74bmr1824716fac.8.1762620207646; Sat, 08 Nov 2025 08:43:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Y6uDouee1vB1vrjNPaJogRK+9tYZ4dg6yzXQ5Ym4Sd3A==" Received: by 2002:a05:6870:8996:b0:3d3:2f56:6730 with SMTP id 586e51a60fabf-3e2f1df2a96ls2075561fac.0.-pod-prod-03-us; Sat, 08 Nov 2025 08:43:23 -0800 (PST) X-Received: by 2002:a05:6808:2129:b0:450:507:c77d with SMTP id 5614622812f47-4502a31c240mr1443256b6e.2.1762620203700; Sat, 08 Nov 2025 08:43:23 -0800 (PST) Received: by 2002:a05:690c:5c16:b0:780:f7eb:fdf with SMTP id 00721157ae682-786a51170c0ms7b3; Sat, 8 Nov 2025 08:40:27 -0800 (PST) X-Received: by 2002:a05:690e:d41:b0:63f:a3bf:b7ff with SMTP id 956f58d0204a3-640d4521905mr2248804d50.2.1762620026315; Sat, 08 Nov 2025 08:40:26 -0800 (PST) Date: Sat, 8 Nov 2025 08:40:25 -0800 (PST) From: Daniel Buchner To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_118566_1835902504.1762620025759" X-Original-Sender: danieljb2@gmail.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.5 (/) ------=_Part_118566_1835902504.1762620025759 Content-Type: multipart/alternative; boundary="----=_Part_118567_1259592482.1762620025759" ------=_Part_118567_1259592482.1762620025759 Content-Type: text/plain; charset="UTF-8" I agree with Greg, 0 quantification of what defines success has been provided for the generally expressed intention of reducing spam. If one admits any decentralized system that allows user-derived public keys / hashes fundamentally includes the ability to embed spurious data in place of those values, eliminating the spamming of those values is effectively impossible. That leaves us with the question: given the goal is simply 'reduction of spam', what defines success and what are the limiting principles? If success is 'reduce spam as much as possible', that would implicitly mean one should remove virtually all OP codes and leave Bitcoin with only basic send/receive that utilizes as few public keys and hashes as possible. Through this rational, empirical lens, I just don't see how this PR's seemingly arbitrary modifications of Bitcoin's protocol rules 1) actually reduce spam (likely will just result in spammers using different constructions), and 2) achieve mitigation of the hazy legal concerns that were a primary driver of this initiative. Can you please quantify what amounts/measurables you are targeting, and explain why this PR will achieve reductions to those level, such that they deliver on desired outcomes? Please connect whatever realistically achievable level reductions you believe will occur to the real world effects you believe they will deliver, such as "If we can just ensure no block can contain more than X bytes of spam, the Three-Letter Agency Y will not come after us because Z rule/limit/law/regulation says so". I am just providing an example of linking action to outcome delivery, so if you don't like that one, please provide whatever you feel best conveys it. Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? As that concern as expressed has a threshold of "any at all" and could just as well be performed via a "less commonly abused" path? Would you also agree the same for essentially all other forms-- that they'd simply made a few line of code changes and then evade these restrictions? In light of that, how would the very real and significant reductions in intentional functionality (such as efficient "few of dozens" multisigs or other such constructs) be justified? How could the confiscation risk be justified? How could the deployment costs be justified? How could the "policy risk" be justified? (E.g. that bitcoin could be driven or forced in to an endless sequences of 'update' blocking actions, each carrying its own risk and disruptions) Although your description of changes is vague and it's not possible to tell for sure without seeing the actual updates-- I don't think your suggested revisions will move your proposal off from having essentially zero risk of adoption, and if it were adopted (which I think is unlikely) I think it's a certainty that there would be a countering fork to continue a Bitcoin without these poorly justified (even essentially useless) restrictions. -- 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/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com. ------=_Part_118567_1259592482.1762620025759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Greg, 0 quantification of what defines success has b= een provided for the generally expressed intention of reducing spam. If one= admits any decentralized system that allows user-derived public keys / has= hes fundamentally includes the ability to embed spurious data in place of t= hose values, eliminating the spamming of those values is effectively imposs= ible. That leaves us with the question: given the goal is simply 'reduction= of spam', what defines success and what are the limiting principles? If su= ccess is 'reduce spam as much as possible', that would implicitly mean one = should remove virtually all OP codes and leave Bitcoin with only basic send= /receive that utilizes as few public keys and hashes as possible. Through t= his rational, empirical lens, I just don't see how this PR's seemingly arbi= trary modifications of Bitcoin's protocol rules 1) actually reduce spam (li= kely will just result in spammers using different constructions), and 2) ac= hieve mitigation of the hazy legal concerns that were a primary driver of t= his initiative.

Can you please quantify what amounts/measurables= you are targeting, and explain why this PR will achieve reductions to thos= e level, such that they deliver on desired outcomes? Please connect whateve= r realistically achievable level reductions you believe will occur to the r= eal world effects you believe they will deliver, such as "If we can just en= sure no block can contain more than X bytes of spam, the Three-Letter Agenc= y Y will not come after us because Z rule/limit/law/regulation says so". I = am just providing an example of linking action to outcome delivery, so if y= ou don't like that one, please provide whatever you feel best conveys it.
<= span>
Would you then agr= ee that this proposal will fail at its stated purpose, particularly with re= spect to concerns about potentially 'unlawful' material?=C2=A0 As that conc= ern as expressed has a threshold of "any at all" and could just as well be = performed via a "less commonly abused" path?=C2=A0 Would you also agree the= same for essentially all other forms-- that they'd simply made a few line = of code changes and then evade these restrictions?
<= br />
In light of that, how would the very real and = significant reductions in intentional functionality (such as efficient=C2= =A0"few of dozens" multisigs=C2=A0or other such constructs) be justified? H= ow could the confiscation=C2=A0risk be justified?=C2=A0 How could the deplo= yment costs be justified?=C2=A0 How could the "policy risk" be justified? (= E.g. that bitcoin could be driven or forced in to an endless sequences of '= update' blocking actions, each carrying its own risk and disruptions)

Although your description o= f changes is vague and it's not possible to tell for sure without seeing th= e actual updates-- I don't think your suggested revisions will move your pr= oposal off from having essentially zero risk of adoption, and if it were ad= opted (which I think is unlikely) I think it's a certainty that there would= be a countering fork to continue a Bitcoin without these poorly justified = (even essentially useless) restrictions.

--
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/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com.
------=_Part_118567_1259592482.1762620025759-- ------=_Part_118566_1835902504.1762620025759--