From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 09 Nov 2025 15:34:48 -0800 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vIEvm-0007sG-0E for bitcoindev@gnusha.org; Sun, 09 Nov 2025 15:34:47 -0800 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-45033344baesf3158716b6e.1 for ; Sun, 09 Nov 2025 15:34:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762731280; cv=pass; d=google.com; s=arc-20240605; b=QXvhhFmRN70Hh5gMIkQ84wn0lAHMmI30IFlltznoFookjr9KML97hR9oQJnaslfF3g Qga7Ab3lQD1AXfn0WFjlJbrUn4pBvPGGfFihanAmfmwgHDLN4wDzdccAZhjy1b6SzRp8 1PZt5KBg/qftiYCkgBf7e2Nj6TWyYuYQu7qNUcw3WjZ0ygvYJKFLxp3xNuTJeYjxPjzL DOX6UiLAfwZcyEK3sXGTE8V1Ud2+90fAdSILBEK/Jn54Vz4/RCyk2anAdwQJVJD5mqJG PxLb5K0Y9SHCUKIl7+QU5/tL3rDmtA7HfWlGSO8g94iotObkEwbLs4kfEZXMQJqz7yRq HAGA== 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=ocDREhhOyP9w/+wLk7NpESJP/eUylOxUKPY2oyoWt0c=; fh=PNEk/3wKfMCEyNMO0Xl3LTO9c0aNqoZuCVeOrDGUYJo=; b=hu8J1Yt3ZxDltNnlNc+LMTWdPGjiSb+NpolbIEyEsMXa6joZO2ov1sP6FO67rOyCDy XUAq5KRbsz6NRedRlYlc0HZcxCFzOwB8+YaYui2S7C8tKMD4RIkV26bmgM2o2zA42Ypl c4AzTpYkvbAh00ExnyFajPVRldAX76nHAkPU8EUI98ZRPNbSCmk+ileWCwi4l/JBXoCY rKF+Y/7EFTZl9wYDMAVxMaXMif8yRph/4pbi2M9qTGNnWaydaZqYMiOt47gQbEIW0VZD 7DVX/VBzaeCXp4kJSwbGss79MNdTqTZOSAuheTcqY90cTSpbhc1JXNAkajqJj0GW7i2x zBlQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=EWksamPk; spf=pass (google.com: domain of dathonohm@proton.me designates 79.135.106.99 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=1762731280; x=1763336080; 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=ocDREhhOyP9w/+wLk7NpESJP/eUylOxUKPY2oyoWt0c=; b=QZhfWv3rUODoLGuwjED543IGjNFTjx53osH33m1y/0uh8xC2vo0Lx3K6JFey3rRkes lhSpgF84WMbWoSJZkrnedjSsZ+ZaGL9w+EU3q5jmaUEQAQxVKiwDqyHwkG9nowLTFAIj gRvyocYlnSZzUlR6IY8twWuqU1aN+iBECMH/oM/gR2vPDmcOsPvO7kOVvB7QlTmzAFYU K6eTPvj51EKMyfeVpmb0QzEsgwIO0zfAIeojgPjyESG8sd8p/3yrm/b7srxgaDBzs2BR yvpnK/bUgHJmzqgzZqQplQAt0cp4Oz9KpNTFb984FHwoN8Ik8/0hOV1jQI+vYfPZZjgO q3gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762731280; x=1763336080; 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=ocDREhhOyP9w/+wLk7NpESJP/eUylOxUKPY2oyoWt0c=; b=M0qR4qha2Lsq0qZ82eiOR2JVrycmNRYVwvWKVJHyBgUZNMqxyZBEEO5n7F5m9FKD07 gULU1zrh4FeP9Ob9Z3mkTOX6uj8B4osxcGePxSyThu3d7On5KE+UhjK5olJXmKNkWI5N h5aM//leOwKaYzdeM8XkdsM0tYDIYxMiyx3idke9xkYg+mLm4EPbO/FxxC9LmLfrQ0UE +OebYYCnh6/Sgz2M92Rv/q5Gfn52/citOdjSWrzkWcZ4Z9yXTMVVXMpQvkqP0981Fbyn zApwtYXVRWwwZXsyRBTB1Gp0b/Rj05fZuTJJNnq04damLQLUjSYiDUY4zoz6x9Uok4aA NflQ== X-Forwarded-Encrypted: i=2; AJvYcCV2A6h6ITTvDji/7enyYEKYYNjXcTgVTC26hwDpJen6Av1XyhylmvY3DKJR8XncnM2dG7Hvi5fSsiao@gnusha.org X-Gm-Message-State: AOJu0YwZZIcTpwjRituDTNUP3aBSDJzgtkHwvsFNmkj3ydom9nd0YalL ngwlmQ9bRiXEdPa+7hTKMOKDkUSu8SfrPE4w5CQ679t7RZfjtXpTW7aN X-Google-Smtp-Source: AGHT+IE8tQ9SlJ63TQmwfvcRxg+WhpsfzIBppYS2xK+nGPWtYCCyiadBxPCjK4m6spIbBIeHru9eSw== X-Received: by 2002:a05:6808:2f18:b0:450:c34:d3c1 with SMTP id 5614622812f47-4502a25a5b9mr3938932b6e.13.1762731279598; Sun, 09 Nov 2025 15:34:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZxjZGhjcIXjE4GMufEVqTMW1jgxltj3OWNA5xjHdKI5Q==" Received: by 2002:a05:6870:2e0f:b0:3de:cd92:aba0 with SMTP id 586e51a60fabf-3e2f4d5daabls3447753fac.1.-pod-prod-01-us; Sun, 09 Nov 2025 15:34:35 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUOVOBT01TDmnOTFEUgf0MrPTf1iv5oX0nKXuQnG2o6yWv65nYMItXg7cNXqvE9h7GByQx9bR2deUyS@googlegroups.com X-Received: by 2002:a05:6808:1309:b0:44f:e3d2:59e3 with SMTP id 5614622812f47-4502a3fe868mr3204293b6e.32.1762731275823; Sun, 09 Nov 2025 15:34:35 -0800 (PST) Received: by 2002:a05:600c:3208:b0:471:13aa:415a with SMTP id 5b1f17b1804b1-47761ca6879ms5e9; Sun, 9 Nov 2025 12:07:17 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXgjDnNqxmFTB+mNPf8BKZluAdgi2mWTrSpF7GfyIpdIC4ccRbNXcgZ8osfz/ZZxitKtYRsdHDj1AKL@googlegroups.com X-Received: by 2002:a05:600c:314a:b0:477:79f8:daa8 with SMTP id 5b1f17b1804b1-47779f8dd3dmr17828475e9.17.1762718835490; Sun, 09 Nov 2025 12:07:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762718835; cv=none; d=google.com; s=arc-20240605; b=JrMH/AgE6OXCOHWV/b2tpBuugrTDDw1PUp7CJ6j39vbDIN9SKX05zlJVvDzXZ0x2ap feAyZuv2lMwtPpsc63s6ZFvhRTwml0/rD+c8MWeE6rT7WCU0TqOr6UKahsr3XrjEknjF 6eBkFnvcwj3E/X5bi+Djlt24tpGXDGu61m7VO0rQeJXJNR/O44BIvt15GPvt78c9sLcW vtQYkptRJ9UrpNqNNFm2B23WHlmEPXcKa6TYIvkkBF/cZXRi+w4l5CYMJ6iY5xNoEMdh UL/4QQn2kdTdGNn+crAZ4kFSt4KS//eyK3dI+k1rW2HiEC/34zVPkQpzHvVleRNXKi4G sQfw== 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=di81nJau8IgrXpVhQUbWovPYAqX7yfKej9cSLriVv6Y=; fh=/mo6jA4YG9HGYP2mH7wofunfRHc374emrp7LyWaEHqw=; b=K2ilm45YCbPebHyQ1/LAJ5tLMmJ3b57ZY93MOG4hWDkvpP4TyKI0zfObhNEtV2qIpN XaGDTD/LDFCoJ+mMPQest4SYv0c+3wPoyqmeo52Wbasn6LhpN88AEF6pGjf33xccySIY kMPi76bULz6asNj7lxPtw46NOiMLGRddIJLjmu+5x4i8AJipQ3GWMp2Cqe2zxaALwIK2 DOKaJavz98CrpFY+0rcerTb/z1Dkw02/eE09P2oNR62VcNTrt6J0rUedxkAMuH35h7FP iyuzJvXVQtnFRqzv0dgr/FnoNSjz9XPUTKNlfPrVpHTGDe8wXvDSrcHIzn5fws/LjHe5 0AFg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=EWksamPk; spf=pass (google.com: domain of dathonohm@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch. [79.135.106.99]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42b2b05eccfsi216526f8f.0.2025.11.09.12.07.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Nov 2025 12:07:15 -0800 (PST) Received-SPF: pass (google.com: domain of dathonohm@proton.me designates 79.135.106.99 as permitted sender) client-ip=79.135.106.99; Date: Sun, 09 Nov 2025 20:07: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: <4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me> In-Reply-To: References: Feedback-ID: 164672733:user:proton X-Pm-Message-ID: 1e27097b1dc99c05f9f61572d0e015a29cffa4f9 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_o3F3DMaqYjsTP2sPACh734IVWZ8v8fhnxJKvgvu1Xjg" 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=EWksamPk; spf=pass (google.com: domain of dathonohm@proton.me designates 79.135.106.99 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=_o3F3DMaqYjsTP2sPACh734IVWZ8v8fhnxJKvgvu1Xjg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg - >It's not speculative-- nlocktime is a day one feature which *is* used in B= itcoin. Correct, I have not claimed otherwise. >Sure someone could footgun themselves by intentionally using a transaction= field which is expressly intended for forward compatibility and get themse= lves burned-- but they'd have to be trying, not just doing a boring and unc= oncerning thing because those fields don't do anything so the only reason t= o use them would be an outright error or intentionally trying to break them= selves. Okay, if you or anyone can show me an example of a "boring and unconcerning= thing" that involves pre-signed transactions that use deep/OP_IF-containin= g Taptrees and timelocks, which predates the original softfork proposal, I = will be happy to update the BIP. Saying "someone might be doing this" is si= mply frivolous obstructionism which, again, could be used to stop any attem= pt to change the consensus rules. >This is also not a new concern being raised for your proposal, every softf= ork post P2SH has been analyzed under this lens so it's quite concerning to= see the proposal here simply ignore the concern. I believe the utility of the strategy of "don't break any use cases, no mat= ter how pathological" has finally worn out. The longer we continue down thi= s path, the more likely it is that Bitcoin will become entirely pathologica= l use cases. Accordingly, this BIP intentionally disrupts all of the most harmful use ca= ses, because they are making Bitcoin worse money and the problem is acceler= ating. But as stated before, the proposal also takes great pains not to dis= rupt any non-pathological use cases, and again I'm open to revising the spe= c if a concrete example that would be harmed by this softfork is found. >And indeed I haven't read a new version because your prior message provide= d no reference to it It is attached as a file to my email. Does your email client not support at= tachments? I'll be sure to include a browser-friendly link next time if tha= t's the case. >I was responding to the summary. The summary mentioned that I had removed all references to legal risks. >Now looking at it, I see that you are still limiting scriptpubkey sizes st= rictly-- this will absolutely confiscate funds as was pointed out and not r= esponded to even before your proposal. (because luke-jr proposed just that = limit first-- actually a more relaxed version, then simply dishonestly insi= sted there was no opposition to it, even though opposition was immediately = raised on the list). If you're referring to [Andrew Poelstra's message here](https://groups.goog= le.com/g/bitcoindev/c/YO8ZwnG_ISs/m/4KvpvYNEAgAJ), that doesn't strike me a= s "opposition", and besides, note that this proposal implements a very simi= lar mitigation suggestion, which was: >In any case, if confiscation is a worry, as always we can exempt the current UTXO set from the rule -- if you are only spending outputs that existed prior to the new rule, your new UTXOs are allowed to be large. The current proposal exempts inputs that spend from the current UTXO set, b= ut does not allow such transactions to create outputs that violate the new = rules. This should be fine, since the funds can just be sent to a different= wallet, (assuming there is actually wallet software somewhere that habitua= lly creates outputs with scriptPubKeys larger than 34 bytes). Please let me know if this is not the "opposition" you were referring to; I= searched for a while but it's possible I missed something. Again, I am eag= er to address all valid technical objections to this proposal, and so far I= haven't seen any. >I think your proposal continues to have no serious prospect of activation I disagree. I think Bitcoin users are fed up with data spam and ready to co= ordinate to say "enough is enough". >should it activate in any form it will just be forked against That would be incredibly risky, but of course people are welcome to run wha= tever software they choose. >and its authors will likely find themselves mired in litigation by people = harmed by it Just to clarify, are you saying that anyone who doesn't support the URSF wi= ll face legal risks? >I think you'll find that almost every significant bitcoin developer will s= tand against such a change and will not work on a fork that adopts them, I = also doubt the market would value your fork with such significant limitatio= ns very highly. I think you are mistaken. The Bitcoin community wants Bitcoin to be money, = not data storage. Best, Dathon On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell wrote: > It's not speculative-- nlocktime is a day one feature which *is* used in = Bitcoin. > > Sure someone could footgun themselves by intentionally using a transactio= n field which is expressly intended for forward compatibility and get thems= elves burned-- but they'd have to be trying, not just doing a boring and un= concerning thing because those fields don't do anything so the only reason = to use them would be an outright error or intentionally trying to break the= mselves. > > This is also not a new concern being raised for your proposal, every soft= fork post P2SH has been analyzed under this lens so it's quite concerning t= o see the proposal here simply ignore the concern. > Even the intentional forward compat features have caused some lack of com= fort in the past in this respect, which is why tapscript OP_SUCCESS works t= he way it does: so that any script that prematurely uses a 'success' opcode= would be inherently completely insecure-- an important improvement in upgr= adability that your proposal permanently destroys without you even understa= nding why it existed in the first place. > > And indeed I haven't read a new version because your prior message provid= ed no reference to it-- it said you were requested to update the list and t= hen you only provided a summary. I was responding to the summary. > > Now looking at it, I see that you are still limiting scriptpubkey sizes s= trictly-- this will absolutely confiscate funds as was pointed out and not = responded to even before your proposal. (because luke-jr proposed just that= limit first-- actually a more relaxed version, then simply dishonestly ins= isted there was no opposition to it, even though opposition was immediately= raised on the list). > > I think your proposal continues to have no serious prospect of activation= , and should it activate in any form it will just be forked against and its= authors will likely find themselves mired in litigation by people harmed b= y it. I think you'll find that almost every significant bitcoin developer w= ill stand against such a change and will not work on a fork that adopts the= m, I also doubt the market would value your fork with such significant limi= tations very highly. > > On Sat, Nov 8, 2025 at 9:02=E2=80=AFPM wrote: > >> Hi Greg - >> >>>That doesn't address the confiscation problem (although any reduction in= the restriction does reduce it), as there likely exist chains of not yet c= onfirmed (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. >> >> While I completely agree that "confiscation" is a precedent we must avoi= d setting, I think my proposal neither confiscates funds nor sets a bad pre= cedent, 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 u= se cases, as this would necessarily imply permanent ossification. >> >> To illustrate the point: it is possible to design off-chain systems that= "use" any given feature of the Bitcoin protocol, including, for example, O= P_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork p= roposal that redefines the OP_NOP. That is, anyone could intentionally lock= funds into a pathological construction in order to obstruct any given soft= fork. >> >> Thus, if taken to the extreme, the argument that no one should ever have= funds "confiscated", or even temporarily frozen, means that we can never u= pgrade Bitcoin again. So, in the interest of avoiding permanent ossificatio= n, it seems wise for us to compromise somewhere in the middle. I think my p= roposal strikes a good balance. >> >> Of course, if people are reporting that there are known, non-pathologica= l use cases with significant funds locked into pre-signed transactions, the= n of course I will modify the proposal to accommodate them. >> >>>Another issue raised which you have not mentioned is that prior to you m= aking this proposal I received minutes from a meeting which noted that Ocea= n Mining was the true author of this proposal and would be presenting it un= der a false identity in order to conceal their involvement. Will you be cor= recting the record on the true authorship of this work 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 this, both here on this mai= ling list and on the BIP PR, but both times my messages were suppressed by = moderators. >> >> I humbly request that moderators let the public see my response this tim= e, otherwise I'm not sure how the record will ever be corrected: >> >> Though I am in direct communication with some Ocean employees (and the B= IP was originally drafted by one of them), I am not affiliated with Ocean i= n any 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 com= munity, because I and most Bitcoiners I know are concerned about Bitcoin's = future if it embraces data storage as a supported use case. >> >> This proposal is also a significant departure from the original BIP draf= t. >> >>>Would you then agree that this proposal will fail at its stated purpose,= particularly with respect to concerns about potentially 'unlawful' materia= l? >> >> No, I think this proposal is the best way to achieve its stated purpose,= which is to reject the standardization of data storage as a supported use = case, at the consensus level. >> >> It sounds like you haven't read the new version of the BIP, nor my summa= ry above. I attached the document in my previous email message if you are i= nterested. 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: https://github= .com/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 j= ust 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? >> >> Again, this is no longer applicable to the proposal. The new draft makes= significant changes. >> >>>In light of that, how would the very real and significant reductions in = intentional functionality (such as efficient "few of dozens" multisigs or o= ther such constructs) be justified? How could the confiscation risk be just= ified? How could the deployment costs be justified? How could the "policy r= isk" be justified? (E.g. that bitcoin could be driven or forced in to an en= dless sequences of 'update' blocking actions, each carrying its own risk an= d disruptions) >> >> I don't see this softfork as an "update-blocking action"; on the contrar= y, I see it as an update-enabling one. As I stated previously, attempting t= o never disrupt any use cases, no matter how pathological, is the fastest p= ath to ossification. >> >> Indeed, Bitcoin has failed to make any consensus upgrades at all since T= aproot in 2021. The community has been going in circles now for two years b= ecause of pathological use cases introduced by that fork, and this proposal= allows Bitcoiners to say "enough is enough", re-affirm that Bitcoin is mon= ey rather than data storage by disabling all the most popular methods of da= ta abuse, and move on to more exciting things. We could have new upgrades i= n 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 reasoning if you disagree. Inaction is not going to solve this. >> >>>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 t= hink is unlikely) >> >> I don't see much reason not to adopt it, besides fear of softforks in ge= neral, but I'm listening. >> >>>I think it's a certainty that there would be a countering fork to contin= ue a Bitcoin without these poorly justified (even essentially useless) rest= rictions. >> >> I don't see why anyone in their right mind would choose to bet on the ol= d fork where Bitcoin is filled with spam and confused about whether it migh= t want 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 Developme= nt Mailing List wrote: >>> >>>> - "Funds confiscation": due to the presence of UTXOs that would be mad= e 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 height check to make sure only UTXOs that are crea= ted 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 p= roposed rule changes that caused concern here. >>> >>> That doesn't address the confiscation problem (although any reduction i= n 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 co= nfiscation 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 Oce= an Mining was the true author of this proposal and would be presenting it u= nder a false identity in order to conceal their involvement. Will you be co= rrecting 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 p= roposal'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' materi= al? 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 jus= tified? 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 e= ndless sequences of 'update' blocking actions, each carrying its own risk a= nd 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 sugges= ted 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 Grou= ps "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/bitcoin= dev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.co= m. > > -- > 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/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%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/= 4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQS= QRnuxLXquQci12-9uiPPqte4XOqoE8OY%3D%40proton.me. --b1=_o3F3DMaqYjsTP2sPACh734IVWZ8v8fhnxJKvgvu1Xjg Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg -

>It's not speculative-- nlocktime is a day one feat= ure which *is* used in Bitcoin.

Correct= , I have not claimed otherwise.

>Sur= e someone could footgun themselves by intentionally using a transaction fie= ld which is expressly intended for forward compatibility and get themselves= burned-- but they'd have to be trying, not just doing a boring and unconce= rning thing because those fields don't do anything so the only reason to us= e them would be an outright error or intentionally trying to break themselv= es.

Okay, if you or anyone can show me = an example of a "boring and unconcerning thing" that involves pr= e-signed transactions that use deep/OP_IF-containing Taptrees and timelocks= , which predates the original softfork proposal, I will b= e happy to update the BIP. Saying "someone might be doing this" is simply f= rivolous obstructionism which, again, could be used to stop any attempt to = change the consensus rules.

>This is also not a new concern being raised for your pro= posal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern.

I believe the utility of the strategy of "don't break any use cases, no m= atter how pathological" has finally worn out. The longer we continue down t= his path, the more likely it is that Bitcoin will become entirely pa= thological use cases.
=
Accordingly, this= BIP intentionally disrupts all of the most harmful use cases, = because they are making Bitcoin worse money and the problem is accelerating= . But as stated before, the proposal also takes great pains not to disrupt = any non-pathological use cases, and again I'm open to revising the spec if = a concrete example that would be harmed by this softfork is found.

>And indeed I haven't read a new version bec= ause your prior message provided no reference to it

It is attached as a file to my email. Does your email client n= ot support attachments? I'll be sure to include a browser-friendly link nex= t time if that's the case.

>I was re= sponding to the summary.

The summary me= ntioned that I had removed all references to legal risks.

>Now looking at it, I see that you are still limiti= ng scriptpubkey sizes strictly-- this will absolutely confiscate funds as w= as pointed out and not responded to even before your proposal. (because luk= e-jr proposed just that limit first-- actually a more relaxed version, then= simply dishonestly insisted there was no opposition to it, even though opp= osition was immediately raised on the list).

If you're referring to = Andrew Poelstra's message here, that doesn't strike me as "opposition",= and besides, note that this proposal implements a very similar mitigation = suggestion, which was:

>In any case,= if confiscation is a worry, as always we can exempt the
current UTXO set from the rule -- if you are only spending outputs that
existed prior to the new rule, your new UTXOs are allowed to be large.<= /div>

The current proposal exempts input= s that spend from the current UTXO set, but does not allow such transac= tions to create outputs that violate the new rules. This should be fine, si= nce the funds can just be sent to a different wallet, (assuming there is ac= tually wallet software somewhere that habitually creates outputs with scrip= tPubKeys larger than 34 bytes).

Please = let me know if this is not the "opposition" you were referring to; I search= ed for a while but it's possible I missed something. Again, I am eager to a= ddress all valid technical objections to this proposal, and so far I haven'= t seen any.

=
>I think your proposal c= ontinues to have no serious prospect of activation

I disagree. I think Bitcoin users are fed up with data spam and= ready to coordinate to say "enough is enough".

>should it activate in any form it will just be forked against<= /div>

That would be incredibly risky, but o= f course people are welcome to run whatever software they choose.

>and its authors will likely find themselves = mired in litigation by people harmed by it

Just to clarify, are you saying that anyone who doesn't support the URS= F will face legal risks?

>I think yo= u'll find that almost every significant bitcoin developer will stand agains= t such a change and will not work on a fork that adopts them, I also doubt = the market would value your fork with such significant limitations very hig= hly.

I think you are mistaken. The Bitc= oin community wants Bitcoin to be money, not data storage.

Best,

Dathon
=
On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell <gmaxwe= ll@gmail.com> wrote:
It's not speculative-- nlocktime is a day= one feature which *is* used in Bitcoin.

Sure some= one could footgun themselves by intentionally using a transaction field whi= ch is expressly intended for forward compatibility and get themselves burne= d-- but they'd have to be trying, not just doing a boring and unconcerning = thing because those fields don't do anything so the only reason to use them= would be an outright error or intentionally trying to break themselves.

This is also not a new concern being raised for= your proposal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern.

Even the intentional forward compat features have caused some lack= of comfort in the past in this respect, which is why tapscript OP_SUCCESS = works the way it does: so that any script that prematurely uses a 'success= ' opcode would be inherently completely insecure-- an important improvement= in upgradability that your proposal permanently destroys without you even = understanding why it existed in the first place.

A= nd indeed I haven't read a new version because your prior message provided = no reference to it-- it said you were requested to update the list and then= you only provided a summary. I was responding to the summary.
Now looking at it, I see that you are still limiting scriptpub= key sizes strictly-- this will absolutely confiscate funds as was pointed o= ut and not responded to even before your proposal. (because luke-jr propose= d just that limit first-- actually a more relaxed version, then simply dish= onestly insisted there was no opposition to it, even though opposition was = immediately raised on the list).

I think your prop= osal continues to have no serious prospect of activation, and should it act= ivate in any form it will just be forked against and its authors will likel= y find themselves mired in litigation by people harmed by it. I think you'= ll find that almost every significant bitcoin developer will stand against = such a change and will not work on a fork that adopts them, I also doubt th= e market would value your fork with such significant limitations very highl= y.


On Sat, Nov 8, 2025 at 9:02=E2=80=AFPM <dathonohm@proton.me> wrote:
Hi Greg= -

>That doesn't address the confiscation problem (although an= y reduction in the restriction does reduce it), as there likely exist chain= s of not yet confirmed (and potentially timelocked) transactions that invol= ve violations of this rule. Those would appear to the network to be output= s created at a later time, although they really weren't. It's unclear to m= e why you haven't yet understood this point.

While I completely a= gree that "confiscation" is a precedent we must avoid setting, I think my p= roposal neither confiscates funds nor sets a bad precedent, as it takes pai= ns to avoid causing problems for all known use cases. I don't think it is r= easonable never to create problems for all unknown use cases, as thi= s would necessarily imply permanent ossification.

To illustrate t= he point: it is possible to design off-chain systems that "use" any given f= eature of the Bitcoin protocol, including, for example, OP_NOPs. Funds lock= ed in such UTXOs would be "confiscated" by the softfork proposal that redef= ines the OP_NOP. That is, anyone could intentionally lock funds into a path= ological construction in order to obstruct any given softfork.

Th= us, if taken to the extreme, the argument that no one should ever have fund= s "confiscated", or even temporarily frozen, means that we can never upgrad= e Bitcoin again. So, in the interest of avoiding permanent ossification, it= seems wise for us to compromise somewhere in the middle. I think my propos= al strikes a good balance.

Of course, if people are reporting tha= t there are known, non-pathological use cases with significant funds locked= into pre-signed transactions, then of course I will modify the proposal to= accommodate them.

>Another issue raised which you have not me= ntioned 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 thei= r involvement. Will you be correcting the record on the true authorship of= this work and on whose behalf its being performed?

It sounds lik= e you have fallen victim to some false rumors.

I already attempte= d to correct the record on this, both here on this mailing list and on the = BIP PR, but both times my messages were suppressed by moderators.

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:

Th= ough I am in direct communication with some Ocean employees (and the BIP wa= s originally drafted by one of them), I am not affiliated with Ocea= n in any way. I am just a Bitcoin dev who is concerned about the i= mplications of Core 30 having been released and gaining adoption.

I am acting solely on my own behalf and on the behalf of the Bitcoin co= mmunity, because I and most Bitcoiners I know are concerned about Bitco= in's future if it embraces data storage as a supported use case.

= This proposal is also a significant departure from the original BIP draft.<= /div>

>Would you then agree that this proposal will fail at its stat= ed purpose, particularly with respect to concerns about potentially 'unlawf= ul' material?

No, I think this proposal is the best way to achie= ve its stated purpose, which is to reject the standardization of data stora= ge as a supported use case, at the consensus level.

It sounds lik= e you haven't read the new version of the BIP, nor my summary above. I atta= ched the document in my previous email message if you are interested. It re= moves 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: https://github.com/dathonohm/bips/blob/r= educed-data-v2/bip-%3F%3F%3F%3F.mediawiki

>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 s= ame for essentially all other forms-- that they'd simply made a few line of= code changes and then evade these restrictions?

Again, this is n= o longer applicable to the proposal. The new draft makes significant change= s.

>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 confiscatio= n risk be justified? How could the deployment costs be justified? How cou= ld the "policy risk" be justified? (E.g. that bitcoin could be driven or fo= rced in to an endless sequences of 'update' blocking actions, each carrying= its own risk and disruptions)

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

Indee= d, Bitcoin has failed to make any consensus upgrades at all since Taproot i= n 2021. The community has been going in circles now for two years because o= f 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 the most popular methods= of data abuse, and move on to more exciting things. We could have new upgr= ades in one year if Bitcoiners focus on building them over the following mo= nths.

I honestly don't see a better way out of this morass, but p= lease let me know 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 having essentially zero risk of adoption, and if it = were 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 liste= ning.

>I think it's a certainty that there would be a counteri= ng fork to continue a Bitcoin without these poorly justified (even essentia= lly useless) restrictions.

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

<= /div>
Best regards,

Dathon
On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmaxwell@gmail.com> wrote:
On Sat, Nov 8, 2025 at 12:58= =E2=80=AFAM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
    <= li style=3D"list-style-type:"1) "">"Funds confiscation": du= e to the presence of UTXOs that would be made temporarily unspendable by th= is proposal, commenters were concerned that this would set a precedent of "= confiscation". This new draft resolves this concern by adding a UTXO height= check to make sure only UTXOs that are created while the softfork is ac= tive will be made temporarily unspendable. The "OP_IF in Tapscript" and= "257-byte control block limit" were the two main proposed rule changes tha= t 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 c= onfirmed (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 have= n't yet understood this point.

I don't think this = concern was in any way limited to the control block of op_if components eit= her, essentially every aspect of the proposal has confiscation issues.

Another issue raised which you have not mentioned is t= hat prior to you making this proposal I received minutes from a meeting whi= ch noted that Ocean Mining was the true author of this proposal and would b= e presenting it under a false identity in order to conceal their involvemen= t. Will you be correcting the record on the true authorship of this work a= nd 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@googl= egroups.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 "= 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://grou= ps.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG= 0%2BVZEcaAw%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/4LP7J-= 1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxL= XquQci12-9uiPPqte4XOqoE8OY%3D%40proton.me.
--b1=_o3F3DMaqYjsTP2sPACh734IVWZ8v8fhnxJKvgvu1Xjg--