From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 07:48:07 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHlAd-00083J-2U for bitcoindev@gnusha.org; Sat, 08 Nov 2025 07:48:07 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3d19dd7137asf3405150fac.0 for ; Sat, 08 Nov 2025 07:48:06 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762616880; cv=pass; d=google.com; s=arc-20240605; b=RMn/1Jw7KNUHUzLh6wrjCNelgXVx6YcZpzYcPeS1VVF24yBrfVh06XoNskXF2glh7b D7FBSvRRwT0vpofnU7X6x1o55muBeD//0u86SMTYRssDYNuR/2Fc9rF9BAQPmi+3T5np Jr85X9noqrw0xtCDClf4/l7Jqv41ypvZxVYteY+6XxHC8rznYlRT2U0/ecWZWLW0YmLe HUgfSD6XtAtnSuO/RZqgocwG0l1LXh6dj6iOe2+hmUr3/38tGNqZV4JP4SXjZbYa6K4K 7XQ9ZJy1V6GIjZRJS1eRGcjjU4zZWfKJ3fDBe/w4LU9o6w9sICtXM8vWhYevp26b3bdT dP0A== 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 :dkim-signature; bh=SYpaX4buWyN9RCSCGhZMelovro6fCvNyUnREIGcYEns=; fh=yYxglLyjoxby8CyB2S7C4Wg1668iGHOAvw4y2bNbuVU=; b=OIS9MnPfZay6B018+P3DaLEfn3wkB5NGpVmmuYWzs/1Eq728ClF4/3stMGdodGVnb6 UNanujIIbM7Wjta1fALLXXCar11EWiN4WfChhjKwTFU4hB7wx58V3Iu96Ii+F5j7YDAP gnASxkpypRPblY9vzTkgrDba9xxnqeu8xa5xZWvhhHzo46BVGHQNqT2cQx9igohthUDb eQpzKjGq+TYHBv/WqOyR4h1lq3/XUjyH20hoka/t0Hl7F4eaZKKkp7hgp944D1onCvLP 1GYIyPyLM069ePDs8y+DjMayuV4jxui3LATvXEPMB8BCOtDtDjugyKBPx87jvb23TSV0 4QNA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ntm2ShFo; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762616880; x=1763221680; 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=SYpaX4buWyN9RCSCGhZMelovro6fCvNyUnREIGcYEns=; b=NRgU9WQoTETwUOwKMM3CJVqk2fCTNvbFEGCMc8xlhbFMtaAtkHgGfhCTqTF5s2QKi9 eUR1jGClqPqMEOmaJe0Olv72UKbW3pif9rOQtiu3RIpMSrcdCkIrf+/9VE15+fbO9Z17 7TqIaL8WkuUuNEY9idG1AttRTzRQUi77e6mSLQBmBACrUks8yoOMaAJHc0xnX9OWt5OH DNYGoVcof5Jox0Svby5KTdYk/e4TFM+ony/uksT9B7cxybS5uyrODaf7SEqgRvjTfBiI OMArECqp09csf6qz5ISaJLW6T0Zw0rCOBmw+RMu2wYITPclwSiEU/s0W/CORWyUck76c HHqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762616880; x=1763221680; 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:from:to:cc:subject:date:message-id:reply-to; bh=SYpaX4buWyN9RCSCGhZMelovro6fCvNyUnREIGcYEns=; b=kL4zlW2gojAECfBIzYRrGRdU+yn/ih97cHsiUVG4qJzHdQsuxElnfU0jxtRMPKBbeL 4D+6tzlfZCzjY4rJL6+H2/ql5xsn28OXoD489l0Gpcu2O7VQ1OAHSBstZEOR1Mdw6W2U NzFdMNZ6ST9hrxg6r5fQSoOc1gXSYJc4vnsN9nrnrCFGDViX6JZqEDKFlBtvgs+sR5hn T7Si+WxIUkVkv6AXUjBnQTCdQT7WeLJz4TpNnsiwIrtED/Z+BKNhq56OUajYUWOJmmaq jkX3VM+mJla7PS0U4cz9NfcpKK2/3YErW7njKXFtT4SBrdu+cjcxZrfU/n4unPWGI3/u TWeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762616880; x=1763221680; 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-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=SYpaX4buWyN9RCSCGhZMelovro6fCvNyUnREIGcYEns=; b=eoMB8PotClfBydJqVNxMw07GGeO1C12LGGLHF1xGJDXofxi/u12MAhKOv7172Bt1eE eA0C8D5GDVrsm8d7goIo9fMXFeFuWEqRxU0a8F2vfaFp2+BMjVOo3LIbU4rut95jjXKf 1WL8tTteNboqWdO0j4jtnDXWa1tF3WM+wj+cS8p57dpOOUJtkVZwMvJqGbuKUmJHLL/R IivhVkdNol5gCbDTyEJkbQUuQAneTd4pjzYDpA/nkxDNxfva2QNDZGp9wP2dRDg1QAHl 1NWnh7jae1uA4403+OT8VaEVe1lPstpCXE9vgU53aC+H+dK7VZMlBq+UTrGvzeIcotev DWPQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVNUIz9sVKxU4Hi7FMjkqbl+ZaZI+IQLbhc7525bwfHpNj/Kv3X/IymmQWvGQwjusDYQwKaqEufkC8r@gnusha.org X-Gm-Message-State: AOJu0YyWROn64A+LWgfKpIDsLGOBNVyIp92d3Ig7+KVMbAgsVHIm4jNP cSARMlR6gpE1qJvhIwArxzVCxm11Vs6QA0HeKC6YLgfHUGqOQRbtWFq+ X-Google-Smtp-Source: AGHT+IGxtJwV5izOXDdRrOiqMrzglZRqtC13XOSr1Of8UXvW7jTPYvGYti2ioCgF7hkCUS4jXbh5+w== X-Received: by 2002:a05:6870:4794:b0:36c:abe0:83d3 with SMTP id 586e51a60fabf-3e7c2808a0dmr1640049fac.39.1762616880434; Sat, 08 Nov 2025 07:48:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YA4aecWhAyWn/wkl8Hm1yGVUk39+boHDpyvmYOXxosVw==" Received: by 2002:a05:6871:ca4b:b0:31d:8e96:6f5e with SMTP id 586e51a60fabf-3e2f56735a6ls1661286fac.2.-pod-prod-08-us; Sat, 08 Nov 2025 07:47:55 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXbg+ZDvNzXjNelP2aXlI5iqynx5uZR++LuteA8AlO0MhyNHV3cw0HpxJB/smEz36FQhvNlLzNOkT4J@googlegroups.com X-Received: by 2002:a05:6808:144f:b0:43d:498c:2157 with SMTP id 5614622812f47-4502a317999mr1217574b6e.29.1762616875600; Sat, 08 Nov 2025 07:47:55 -0800 (PST) Received: by 2002:a05:6808:1ddd:b0:450:1552:6123 with SMTP id 5614622812f47-450155265femsb6e; Sat, 8 Nov 2025 07:38:30 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWiJ44CjgWsbx5I51rhJOYq79QHn8CLgVcy7GHvEMe9hb/eKwXEDQi5YakuxCuUX9vo4T+TfvqyWa3v@googlegroups.com X-Received: by 2002:a05:6a00:985:b0:781:1a65:f230 with SMTP id d2e1a72fcca58-7b2270843aamr4151912b3a.26.1762616308854; Sat, 08 Nov 2025 07:38:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762616308; cv=none; d=google.com; s=arc-20240605; b=cV7ISotzQZRBv3yz1EjfabUVwkNO3xxZLsvgqE8I03EOtRVUYsrZU0P4AUmJFUWI45 UwWShMM9bS5cg0qxspkQtu1b3bT6TJe8lFs3Fi8z7FofGoF0WkHOaRFMe3ma12DnMezC My0QkpdgYMleQugBa5+BtLJQARuBEKMZnRptyc5FCq604PF74zQ6UXZjN9HyM+e7JIFy HAMFWvcd/65uSAYq944VI1l+sxjo2CJfGXNZ4GNuQ5rWAkuvFpYoIuvs0V9VkWUIqZiZ MGDfoHapJIxLUeQjs3jF2pgmdAMBZsthoCm2P4QAxET/F1238YyHkjOM7oc+l6CD4w8G kq/A== 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=FC6Qxvjgw8Od1E3ffYpR+vCphQY0niy6orIHKXQjh2I=; fh=2z+1i+lOVbmJGYVvnwmJeeTgWHec5TisJQGQkU03mxI=; b=e/Y//u8zc9g11qJoVsjaLJorbH3pXkMqp1g8RGys099j4U3pcsmIUo8vTnxILKgtNM /OJNfKgNqxVdp92XPOmsaV12b3Rj0gKjitLSPljvwgNueU6idwrcpePD5o3RKIaThGno wKJliZBlf1kB4geX9GfsRDhVaZ+fkX0W48/z/80yZEIM5ngUtA4zRNpN23ZxooahTmSF bg+n5clt+RwuQ97qBgCMbju/bH2WbZlQAvIrnLDYV0JK53h68UIqshcoXVeHt7rvY3yK S3ikaWaPXH02Yx9a/InJY2s73MePFICXebNOW/tHm5g4GxH3rXmLPeOp6kUR2Wdsberk Gf4A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ntm2ShFo; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com. [2607:f8b0:4864:20::1029]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7b0cc36cb51si234032b3a.7.2025.11.08.07.38.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Nov 2025 07:38:28 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) client-ip=2607:f8b0:4864:20::1029; Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-3436a97f092so988903a91.3 for ; Sat, 08 Nov 2025 07:38:28 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCW/MIsPxJu4wj2gWz5JZkunroaPIh9LQ4B2XbZ6WcFmnsOO6iGgBHfmsW6Z0GAd/s7p2UY6vMV1OWrj@googlegroups.com X-Gm-Gg: ASbGncs0Bq4LHEVkISuwhLCA+uPzZOaFpFVf9VaNL/2CHCAnNW8JgX70NNzLUJ7lYEj vABCj7O3BDiIwn07iBW7bVNSiQNuFKEvitqMdlYE/D3qgJO72AwGn22zZengjiC6cf9SsgYJ2a0 X5G4Pxg1oWQkaC3JmYPY00P1tG0PNVaRH4nGIEnX9bmWZ3c9vpO0T9Q7h0578uSatcBbslENCi/ RhlGYetvzMrzCQoYXnF+lQe2B3+Qrd6yz30GMPCBpN1zzouUbFawMaFb8/zkpPfxtSoeREoMdLp /C754dSNdWlpR1p7aLctjFR7QATelUPENHnhctna X-Received: by 2002:a17:903:ac7:b0:295:4d97:84e2 with SMTP id d9443c01a7336-297e56d8ac5mr38758555ad.37.1762616308405; Sat, 08 Nov 2025 07:38:28 -0800 (PST) MIME-Version: 1.0 References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: From: Greg Maxwell Date: Sat, 8 Nov 2025 15:38:16 +0000 X-Gm-Features: AWmQ_bm7Pj73UihAkmuwRsOgY0W5c8AnedGV2KTFXN9FhOvnpfb1VWeX6fUFIZ8 Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: dathonohm@proton.me Cc: Erik Aronesty , Antoine Riard , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000f01a4b0643171668" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ntm2ShFo; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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.5 (/) --000000000000f01a4b0643171668 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM dathonohm via Bitcoin Development M= ailing List wrote: > > 1. "Funds confiscation": due to the presence of UTXOs that would be > made temporarily unspendable by this proposal, commenters were concern= ed > that this would set a precedent of "confiscation". This new draft reso= lves > this concern by adding a UTXO height check to make sure *only UTXOs > that are created while the softfork is active will be made temporarily > unspendable*. The "OP_IF in Tapscript" and "257-byte control block > limit" were the two main proposed rule changes that caused concern her= e. > > That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues. Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? > "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block *all* methods of arbitary data insertion, just the most commonly abused ones. 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. --=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/= CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com. --000000000000f01a4b0643171668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM d= athonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
  1. "Funds confiscation": due to the presence of UTXOs that would = be made temporarily unspendable by this proposal, commenters were concerned= that this would set a precedent of "confiscation". This new draf= t resolves this concern by adding a UTXO height check to make sure only = UTXOs that are created while the softfork is active will be made temporaril= y unspendable. The "OP_IF in Tapscript" and "257-byte co= ntrol block limit" were the two main proposed rule changes that caused= concern here.

That = doesn't address the confiscation problem (although any reduction in the= restriction does reduce it), as there likely exist chains of not yet confi= rmed (and potentially timelocked) transactions that involve violations of t= his rule.=C2=A0 Those would appear=C2=A0to the network to be outputs create= d at a later time, although they really weren't.=C2=A0 It's unclear= to me why you haven't yet understood this point.

<= div>I don't think this concern was in any way limited to the control bl= ock of op_if components either, essentially every aspect of the proposal ha= s confiscation issues.

Another issue raised which = you have not mentioned is that prior to you making this proposal I received= minutes from a meeting which noted that Ocean Mining was the true author o= f this proposal and would be presenting it under a false identity in order = to conceal their involvement.=C2=A0 Will you be correcting the record on th= e true authorship of this work and on whose behalf its=C2=A0being performed= ?

>=C2=A0"This doesn't block all= possible methods of arbitrary data=20 insertion": This was already addressed in the previous draft, but to= =20 reiterate: this proposal's goal is not to block all methods of a= rbitary data insertion, just the most commonly abused ones.

Would you then agree that this proposal= will fail at its stated purpose, particularly with respect to concerns abo= ut potentially 'unlawful' material?=C2=A0 As that concern as expres= sed has a threshold of "any at all" and could just as well be per= formed via a "less commonly abused" path?=C2=A0 Would you also ag= ree the same for essentially all other forms-- that they'd simply made = a few line of code changes and then evade these restrictions?
<= div>
In light of that, how would the very = real and significant reductions in intentional functionality (such as effic= ient=C2=A0"few of dozens" multisigs=C2=A0or other such constructs= ) be justified? How could the confiscation=C2=A0risk be justified?=C2=A0 Ho= w could the deployment costs be justified?=C2=A0 How could the "policy= risk" be justified? (E.g. that bitcoin could be driven or forced in t= o 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 possib= le to tell for sure without seeing the actual updates-- I don't think y= our 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 conti= nue a Bitcoin without these poorly justified (even essentially useless) res= trictions.





=

--
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/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%= 40mail.gmail.com.
--000000000000f01a4b0643171668--