From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 13:58:52 -0800 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHqxP-0005Q2-9Y for bitcoindev@gnusha.org; Sat, 08 Nov 2025 13:58:52 -0800 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3d3cb44c465sf3630635fac.0 for ; Sat, 08 Nov 2025 13:58:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762639125; cv=pass; d=google.com; s=arc-20240605; b=ETeoXdE+qClqNNqhQxnmWKtGu5/w/rX+qDIjtVVFH+Sgk3Qt0DBE9Pzj4aTYMHB8AG S8qt4I/1kHdqRyIghw9BhvYHRF8uNCzK78SqzBKi/4VYy540mn5Af5LXS2dInvwu2/pL wFxuTMvE6aXT+3E7JS5SNMNEdI4GjS2HjrmpqXQ5TwQG3puocDAJbrqFYaGaplJmGRCY PYmTkO2iWDlv6sUiPgXM4+qaUBINLswtv+4u6rcN/cWMEgIPN4f4eXc/SY8OSMjW/Ksd rZdBqKEEztbqg9BBlidzJV7IwJdTN9NpfAl+xiPUZQzn1xl6aDM67Bgmdh5mCEdPc1ok 3Glg== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=duuJ6kJl5kAsSXsv5L3lHTishwOVezP5pTiF5MgvX6o=; fh=nxtkljDK+NnXWl0xA4Kw8Ww8Ml7c+qn72v8TGKJoNqE=; b=UhVlINxRoA2RQtf5eroILHfbtZp4HcotunByAXy+fFSHHwYa/WxgZPpfndYCffzsUq imFbDticXgh4wWeRxjHnBgYNqKZUxPcfie16UmOx6K3fhxjcCt3m1F6kMX6XusR+lsYK Xx3xUG12m4Rj51rBBdedkVaqZjqsUZGO2jGzUUicQ1ddNKaktxTd1aoNWc5gFojTUygc L/WOK7cdMpmINXN/EMDuk4fjPmM4cSXy+JwJeW00ij8p7A8apA51YpU0RJeoTV8+Ht12 GTt4hAU/YxVIXrl+stnX6EK7BKPuCyllj0pDYZAszt+2RJ9P2C7Gw9KZHTJ1StsjL+AH eaUQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=ILvuK3y9; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762639125; x=1763243925; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=duuJ6kJl5kAsSXsv5L3lHTishwOVezP5pTiF5MgvX6o=; b=WTFKnTgfAqNfNYO6TCU400LUgbBqqqa4lLgZYOPMml7cR+YAM+tdaFnIAp06kkCcN/ 71POQki24/8/lWEGi9El1eIFp2osWm+IYD65tWaTNfgjp0wViKQE5TgH8Q9QV1z9NQ1N okYy/Rhff6ImWpMqoeoOrzovDyruCzvqJyX2Qf3g+kK5nqFGULB7oTrMyG6OItMLEnBO JSqRpDDtqJxuI67qbz7/3/ifp8sGTGIt5/5BZ0cDHmEAdExzpIrkdhXx8ZFI3u132D36 gwJ1Ak5zHtdiY42ThppimvgtsL5c7l7nyuPPsdKIOyp7IyfWV4Hk/pgMzQ8jnlE8IDeb 7FHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762639125; x=1763243925; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=duuJ6kJl5kAsSXsv5L3lHTishwOVezP5pTiF5MgvX6o=; b=VCDBaphOYLzGs0iPUIziS1jYxuXVJo1SY7GopaD2knlymo8lCopFGcn1Ft3+nbzZ+1 d2zaZceRcXGMw/cTh/yM1CENaO58EMp8Fn/xAnQUBnJO0OXZbqHyhtWZmnFCLqGUDKXA V6/+kZQHwDUQbEraLfFKDT53oKL10GnKY+WrPxxy/ZIRG0E4KK6VF7HBxx53cmZWdSni Ox5e0Tnobcy6z6cCC6YhM7EpbLh0Z4gXFqaWmgFbCmpK2aJRTZ8r4rFa4VQXsTHtoVzw hticpkIZgCkeQkKm6y7X8E9gmqEjh4wWADSApojoQIyDcaL2B+YzUGgf35KT06vifPEE KaGw== X-Forwarded-Encrypted: i=2; AJvYcCWhgV9IfDWsVRWiXG2/TWf5YbHnekYWlSAOpk9f4wN/CRSPGTXoGnP3PLplw0rDTmH41NNjoD3R2I3u@gnusha.org X-Gm-Message-State: AOJu0Yx/3Rkw93Z5mLbXacmeZosb7BBOAnMFB0Wese7i+pzGoVrfEpOM w0dDCB+BHIMVqqd7pTdWZ/DiWDECU/PuBCmQ5+/SVHpFLhIHs0DMFV9q X-Google-Smtp-Source: AGHT+IH61RRP2C+ME0Eue8IjWhLE08z5PCOPGqItZtepCDSQ+IrSoWXH0qVmRY7/mPfBAbPcXmYXqw== X-Received: by 2002:a05:6871:580f:b0:3d1:f53e:ba47 with SMTP id 586e51a60fabf-3e7c27e1e22mr2463821fac.24.1762639124613; Sat, 08 Nov 2025 13:58:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aCTMCNAS3HIbZqpkrAteWKZx1fl3Y5aL4FzovNCa8HUw==" Received: by 2002:a05:6870:9620:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3e2f1e03579ls3092530fac.0.-pod-prod-09-us; Sat, 08 Nov 2025 13:58:39 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXXfI8AbNogbrSXO2fdNSSfYBq82BS+I8qvgiPgRH2wkdUfwdrfDrMRJBUYaQsu5tAGOAodWuapu2OD@googlegroups.com X-Received: by 2002:a05:6808:4a45:20b0:450:3534:dcb7 with SMTP id 5614622812f47-4503534dd1emr701298b6e.23.1762639119540; Sat, 08 Nov 2025 13:58:39 -0800 (PST) Received: by 2002:a05:6808:655:b0:44f:db81:40fd with SMTP id 5614622812f47-44fee763984msb6e; Sat, 8 Nov 2025 13:02:17 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWl1C9hRq2amYc9Him7awveXiwqnqqTaf6LhL5QfqhWpKQTX12lU1hyUY3ywYMw70eWrHxGiVaj3YFm@googlegroups.com X-Received: by 2002:a17:903:fa5:b0:295:c2e7:7199 with SMTP id d9443c01a7336-297e56acaefmr49218765ad.29.1762635736907; Sat, 08 Nov 2025 13:02:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762635736; cv=none; d=google.com; s=arc-20240605; b=CW968UdBogPx0tMgNdLtfvIeXzP7gWMjRkzUsOEEgvdye9gBcW6W7gFuKnu+1KanFi icuywmrPwf6wGw0QjzDu92Et3gtBbKmyPbGwxNTZk8drabhsqEzIp1wPng1erDrtaiFw DnzeWDTiaoRoMJS3y2pNRzyG9Cu+Ek0mnzsLpuNIpJuzQyMAMpR5cAh2luA0BRAkpWK3 VUXF19YcBJopVg2qTJnE9mxtZq+Rmita9wUckd74XjMIVkyylWC/7bXSAUAfkPzDR9Fb srVLshttBN8LYn5rpLhvK1qH1s0JpDtyW7NeUGRyn9879XL3ZRZ5MGBh4ebjfA3i07Rr hjHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=OydDl0vtOG2g9YvNXqwvItZeVoBUjusFLWobAhfxyL8=; fh=/mo6jA4YG9HGYP2mH7wofunfRHc374emrp7LyWaEHqw=; b=HqmF7YI3W0JHRnqKej0ydQJv2iJqFRXPirkKeEt4vZCoHuM9oDCEmFl7KtTFJJqblf h5BPcxcSaV3+EEZ3rkJFHqKrsXqyBbg/Z19htRTm63s9+fQzlNz2Ib9p6jPdfpqUWrrf u29H0W/VRSNjvMcvpi3IR3PESxiiNsI4+WoQGCLVjU5uq6e4dDcYveJNH203+Nd6/6oH SF5lJg6+7XMczTKDN1kvRZZj/xTQKUtDg4FSQTSZbDFgv0SmE/0dHxKGewKh9jv3SkHo cgji6uMAR1RzgBa+KQlqTp1lPBKCZ+/3iDoCnIscgjk+d2DS+tdHdIS4BPf+QNQuF2XJ /oWg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=ILvuK3y9; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24428.protonmail.ch (mail-24428.protonmail.ch. [109.224.244.28]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-297ef1edc4asi1336025ad.3.2025.11.08.13.02.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Nov 2025 13:02:16 -0800 (PST) Received-SPF: pass (google.com: domain of dathonohm@proton.me designates 109.224.244.28 as permitted sender) client-ip=109.224.244.28; Date: Sat, 08 Nov 2025 21:02:08 +0000 To: Greg Maxwell From: dathonohm via Bitcoin Development Mailing List Cc: Erik Aronesty , Antoine Riard , Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork Message-ID: In-Reply-To: References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> Feedback-ID: 164672733:user:proton X-Pm-Message-ID: 27b6cb4b85d6d4150ef940da6a3398c4bfdd3338 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_1jQgVZgGweIfIwUlT5jFm2vPHq03R9ngFb90uaMNQg" X-Original-Sender: dathonohm@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=ILvuK3y9; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.28 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: dathonohm@proton.me Reply-To: dathonohm@proton.me 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: -1.0 (-) --b1=_1jQgVZgGweIfIwUlT5jFm2vPHq03R9ngFb90uaMNQg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg - >That doesn't address the confiscation problem (although any reduction in t= he restriction does reduce it), as there likely exist chains of not yet con= firmed (and potentially timelocked) transactions that involve violations of= this rule. Those would appear to the network to be outputs created at a la= ter time, although they really weren't. It's unclear to me why you haven't = yet understood this point. While I completely agree that "confiscation" is a precedent we must avoid s= etting, I think my proposal neither confiscates funds nor sets a bad preced= ent, as it takes pains to avoid causing problems for all known use cases. I= don't think it is reasonable never to create problems for all unknown use = cases, as this would necessarily imply permanent ossification. To illustrate the point: it is possible to design off-chain systems that "u= se" any given feature of the Bitcoin protocol, including, for example, OP_N= OPs. Funds locked in such UTXOs would be "confiscated" by the softfork prop= osal that redefines the OP_NOP. That is, anyone could intentionally lock fu= nds into a pathological construction in order to obstruct any given softfor= k. Thus, if taken to the extreme, the argument that no one should ever have fu= nds "confiscated", or even temporarily frozen, means that we can never upgr= ade Bitcoin again. So, in the interest of avoiding permanent ossification, = it seems wise for us to compromise somewhere in the middle. I think my prop= osal strikes a good balance. Of course, if people are reporting that there are known, non-pathological u= se cases with significant funds locked into pre-signed transactions, then o= f course I will modify the proposal to accommodate them. >Another issue raised which you have not mentioned is that prior to you mak= ing 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 unde= r a false identity in order to conceal their involvement. Will you be corre= cting the record on the true authorship of this work and on whose behalf it= s being performed? It sounds like you have fallen victim to some false rumors. I already attempted to correct the record on this, both here on this mailin= g list and on the BIP PR, but both times my messages were suppressed by mod= erators. I humbly request that moderators let the public see my response this time, = otherwise I'm not sure how the record will ever be corrected: Though I am in direct communication with some Ocean employees (and the BIP = was originally drafted by one of them), I am not affiliated with Ocean in a= ny way. I am just a Bitcoin dev who is concerned about the implications of = Core 30 having been released and gaining adoption. I am acting solely on my own behalf and on the behalf of the Bitcoin commun= ity, because I and most Bitcoiners I know are concerned about Bitcoin's fut= ure if it embraces data storage as a supported use case. This proposal is also a significant departure from the original BIP draft. >Would you then agree that this proposal will fail at its stated purpose, p= articularly with respect to concerns about potentially 'unlawful' material? No, I think this proposal is the best way to achieve its stated purpose, wh= ich is to reject the standardization of data storage as a supported use cas= e, at the consensus level. It sounds like you haven't read the new version of the BIP, nor my summary = above. I attached the document in my previous email message if you are inte= rested. It removes all references to legal risks. For those who prefer viewing the proposal in a browser, I have pushed a cop= y of it to a non-PR branch, since the PR is still locked: https://github.co= m/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki >As that concern as expressed has a threshold of "any at all" and could jus= t as well be performed via a "less commonly abused" path? Would you also ag= ree the same for essentially all other forms-- that they'd simply made a fe= w line of code changes and then evade these restrictions? Again, this is no longer applicable to the proposal. The new draft makes si= gnificant changes. >In light of that, how would the very real and significant reductions in in= tentional functionality (such as efficient "few of dozens" multisigs or oth= er such constructs) be justified? How could the confiscation risk be justif= ied? How could the deployment costs be justified? How could the "policy ris= k" be justified? (E.g. that bitcoin could be driven or forced in to an endl= ess sequences of 'update' blocking actions, each carrying its own risk and = disruptions) I don't see this softfork as an "update-blocking action"; on the contrary, = I see it as an update-enabling one. As I stated previously, attempting to n= ever disrupt any use cases, no matter how pathological, is the fastest path= to ossification. Indeed, Bitcoin has failed to make any consensus upgrades at all since Tapr= oot in 2021. The community has been going in circles now for two years beca= use of pathological use cases introduced by that fork, and this proposal al= lows Bitcoiners to say "enough is enough", re-affirm that Bitcoin is money = rather than data storage by disabling all the most popular methods of data = abuse, and move on to more exciting things. We could have new upgrades in o= ne year if Bitcoiners focus on building them over the following months. I honestly don't see a better way out of this morass, but please let me kno= w your reasoning if you disagree. Inaction is not going to solve this. >I don't think your suggested revisions will move your proposal off from ha= ving essentially zero risk of adoption, and if it were adopted (which I thi= nk is unlikely) I don't see much reason not to adopt it, besides fear of softforks in gener= al, but I'm listening. >I think it's a certainty that there would be a countering fork to continue= a Bitcoin without these poorly justified (even essentially useless) restri= ctions. I don't see why anyone in their right mind would choose to bet on the old f= ork where Bitcoin is filled with spam and confused about whether it might w= ant to just be a database, over the new one where Bitcoin is money. Best regards, Dathon On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell wrote: > On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM dathonohm via Bitcoin Development= Mailing List wrote: > >> - "Funds confiscation": due to the presence of UTXOs that would be made = temporarily unspendable by this proposal, commenters were concerned that th= is would set a precedent of "confiscation". This new draft resolves this co= ncern by adding a UTXO height check to make sure only UTXOs that are create= d while the softfork is active will be made temporarily unspendable. The "O= P_IF in Tapscript" and "257-byte control block limit" were the two main pro= posed 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 co= nfirmed (and potentially timelocked) transactions that involve violations o= f this rule. Those would appear to the network to be outputs created at a l= ater 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 conf= iscation issues. > > Another issue raised which you have not mentioned is that prior to you ma= king 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 und= er a false identity in order to conceal their involvement. Will you be corr= ecting the record on the true authorship of this work and on whose behalf i= ts being performed? > >> "This doesn't block all possible methods of arbitrary data insertion": T= his was already addressed in the previous draft, but to reiterate: this pro= posal's goal is not to block all methods of arbitary data insertion, just t= he 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 ju= st as well be performed via a "less commonly abused" path? Would you also a= gree the same for essentially all other forms-- that they'd simply made a f= ew line of code changes and then evade these restrictions? > > In light of that, how would the very real and significant reductions in i= ntentional functionality (such as efficient "few of dozens" multisigs or ot= her such constructs) be justified? How could the confiscation risk be justi= fied? How could the deployment costs be justified? How could the "policy ri= sk" be justified? (E.g. that bitcoin could be driven or forced in to an end= less 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 te= ll for sure without seeing the actual updates-- I don't think your suggeste= d revisions will move your proposal off from having essentially zero risk o= f 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 wi= thout 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/bitcoinde= v/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%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/= MQv8-Ejvo7ZUcCOQkmtFo8hOATgSrKWvtG25JqUgWXKNGYHbCkVc-IawuPcRN_BebLTLQr3QtTT= aA1iWrWgs0fFwI45jnQFi5_ORnAbsP_k%3D%40proton.me. --b1=_1jQgVZgGweIfIwUlT5jFm2vPHq03R9ngFb90uaMNQg Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg -

>That doesn't address the confiscation problem (alt= hough any reduction in the restriction does reduce it), as there likely exi= st chains of not yet confirmed (and potentially timelocked) transactions th= at involve violations of this rule. Those would appear to the network to b= e outputs created at a later time, although they really weren't. It's uncl= ear to me why you haven't yet understood this point.

While I completely agree that "confiscation" is a precedent w= e must avoid setting, I think my proposal neither confiscates funds nor set= s a bad precedent, as it takes pains to avoid causing problems for all know= n use cases. I don't think it is reasonable never to create problems for al= l unknown use cases, as this would necessarily imply permanent ossif= ication.

To illustrate the point: it is= possible to design off-chain systems that "use" any given feature of the B= itcoin protocol, including, for example, OP_NOPs. Funds locked in such UTXO= s would be "confiscated" by the softfork proposal that redefines the OP_NOP= . That is, anyone could intentionally lock funds into a pathological constr= uction in order to obstruct any given softfork.

Thus, if taken to the extreme, the argument that no one should eve= r have funds "confiscated", or even temporarily frozen, means that we = can never upgrade Bitcoin again. So, in the interest of avoiding permanent = ossification, it seems wise for us to compromise somewhere in the middle. I= think my proposal strikes a good balance.

Of course, if people are reporting that there are known, non-pathologic= al use cases with significant funds locked into pre-signed transactions, th= en of course I will modify the proposal to accommodate them.

>Another issue raised which you have not mentioned= is that prior to you making this proposal I received minutes from a meetin= g which noted that Ocean Mining was the true author of this proposal and wo= uld be presenting it under a false identity in order to conceal their invol= vement. Will you be correcting the record on the true authorship of this w= ork and on whose behalf its being performed?

It sounds like you have fallen victim to some false rumors.

I already attempted to correct the record on thi= s, both here on this mailing list and on the BIP PR, but both times my mess= ages were suppressed by moderators.

I h= umbly request that moderators let the public see my response this time, oth= erwise I'm not sure how the record will ever be corrected:

Though I am in direct communication with some Ocean em= ployees (and the BIP was originally drafted by one of them), I am n= ot affiliated with Ocean in any way. I am just a Bitcoin dev who i= s concerned about the implications of Core 30 having been released and gain= ing adoption.

I am acting solely&nbs= p;on my own behalf and on the behalf of the Bitcoin community, because = I and most Bitcoiners I know are concerned about Bitcoin's future if it emb= races data storage as a supported use case.

This proposal is also a significant departure from the original BIP dr= aft.

>Would you then agree that this= proposal will fail at its stated purpose, particularly with respect to con= cerns about potentially 'unlawful' material?

No, I think this proposal is the best way to achieve its stated purpo= se, which is to reject the standardization of data storage as a supported u= se case, at the consensus level.

It sou= nds like you haven't read the new version of the BIP, nor my summary above.= I attached the document in my previous email message if you are interested= . It removes all references to legal risks.

For those who prefer viewing the proposal in a browser, I have pushed = a copy of it to a non-PR branch, since the PR is still locked: <= a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://gi= thub.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki">ht= tps://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.media= wiki

>As that concern as = expressed has a threshold of "any at all" and could just as well be perform= ed via a "less commonly abused" path? Would you also agree the same fo= r essentially all other forms-- that they'd simply made a few line of code = changes and then evade these restrictions?

Again, this is no longer applicable to the proposal. The new draft make= s significant changes.

>In light of = that, how would the very real and significant reductions in intentional fun= ctionality (such as efficient "few of dozens" multisigs or other such const= ructs) be justified? How could the confiscation risk be justified? How cou= ld the deployment costs be justified? How could the "policy risk" be justi= fied? (E.g. that bitcoin could be driven or forced in to an endless sequenc= es of 'update' blocking actions, each carrying its own risk and disruptions= )

I don't see this softfork as an "upda= te-blocking action"; on the contrary, I see it as an update-enabling one. A= s I stated previously, attempting to never disrupt any use cases, no matter= how pathological, is the fastest path to ossification.

Indeed, Bitcoin has failed to make any consensus upgrades = at all since Taproot in 2021. The community has been going in circles now f= or two years because of pathological use cases introduced by that fork, and= this proposal allows Bitcoiners to say "enough is enough", re-affirm that = Bitcoin is money rather than data storage by disabling all th= e most popular methods of data abuse, and move on to more exciting things. = We could have new upgrades in one year if Bitcoiners focus on building them= over the following months.

I honestly = don't see a better way out of this morass, but please let me know your reas= oning if you disagree. Inaction is not going to solve this.

>I don't think your suggested revisions will move y= our proposal off from having essentially zero risk of adoption, and if it w= ere adopted (which I think is unlikely)

I don't see much reason not to adopt it, besides fear of softforks = in general, but I'm listening.

>I th= ink it's a certainty that there would be a countering fork to continue a Bi= tcoin without these poorly justified (even essentially useless) restriction= s.

I don't see why anyone in their righ= t mind would choose to bet on the old fork where Bitcoin is filled with spa= m and confused about whether it might want to just be a database, over the = new one where Bitcoin is money.

Best re= gards,

Dathon
On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmaxwe= ll@gmail.com> wrote:
On Sat, Nov 8, 2025 at 12:58= =E2=80=AFAM dathonohm via Bitcoin Development Mailing List <bit= coindev@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 draft resolves this concern by adding a UTXO heig= ht check to make sure only UTXOs that are created while the softfork is = active will be made temporarily unspendable. The "OP_IF in Tapscript" a= nd "257-byte control block limit" were the two main proposed rule changes t= hat 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= confirmed (and potentially timelocked) transactions that involve violation= s 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 ha= ven't yet understood this point.

I don't think thi= s concern was in any way limited to the control block of op_if components e= ither, 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 w= hich 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 involvem= ent. 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 arbit= ary data insertion, just the most commonly abused ones.

Would you then agree that this proposal wil= l fail at its stated purpose, particularly with respect to concerns about p= otentially 'unlawful' material? As that concern as expressed has a thresho= ld 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 for= ms-- that they'd simply made a few line of code changes and then evade thes= e 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 c= onstructs) be justified? How could the confiscation risk be justified? How= could the deployment costs be justified? How could the "policy risk" be j= ustified? (E.g. that bitcoin could be driven or forced in to an endless seq= uences of 'update' blocking actions, each carrying its own risk and disrupt= ions)

Although your desc= ription 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 mov= e your proposal off from having essentially zero risk of adoption, and if i= t were adopted (which I think is unlikely) I think it's a certainty that th= ere would be a countering fork to continue a Bitcoin without these poorly j= ustified (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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://gr= oups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PX= pd1VbiUFPwATg-g%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.com/d/msgid/bitcoindev/MQv8-E= jvo7ZUcCOQkmtFo8hOATgSrKWvtG25JqUgWXKNGYHbCkVc-IawuPcRN_BebLTLQr3QtTTaA1iWr= Wgs0fFwI45jnQFi5_ORnAbsP_k%3D%40proton.me.
--b1=_1jQgVZgGweIfIwUlT5jFm2vPHq03R9ngFb90uaMNQg--