From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Nov 2025 00:28:44 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vIjk2-0001sQ-B6 for bitcoindev@gnusha.org; Tue, 11 Nov 2025 00:28:44 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-656b7cf5ec0sf1592623eaf.3 for ; Tue, 11 Nov 2025 00:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762849716; x=1763454516; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=aOWrGbEeyBMgrkcVLf9h+uXFDdhvAaaRLmNRd57O1/w=; b=dIYyy0dmdzU/TiCiPC1eLknmYGCpRNrzv03YXGUmMSPkqnvl3gOoDVHW8UeqKyBI67 Zz5HoHo1JsnrK9ijjPgC/Pyxv6EjV+25ilRrpMWXCb2rtVLQ3KYG6cAv9czYv4f0lRoQ sfrnIksxowRDUK6tvQxc52Lnwo6sukX3ssFhNF18652rBs/n1Gq8K/CgkmjRkeY+NWtd EBO9tmhOiffp6ziCn5twHqpxcv6WgT4kOsssaRyQv2IBTvUwn2dgiU1Fg7m5E6sVueoc +a0TO8wZ3w1dqMyK3ruNgv2SvD2Yny16WZlW60BaVTMN4zdJuNrA8IV06+rkPInKIfvb B0MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762849716; x=1763454516; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aOWrGbEeyBMgrkcVLf9h+uXFDdhvAaaRLmNRd57O1/w=; b=uSGJSmHMnHMNQRQoXBVQcqiocotPg/77bYIWMgw9vYAXJmy8n5GgiQNR59kaaSbG92 cCkzlwZrkKjADHRArKGXr75+nQ8jPFYxQsIGsmAFgmHZmzpJmpFS3NJPEWxPp9BqYq2E zN85oBOwg63zlBfdqH0dGT2+rxujs7P7xRCD+j2k8j++yJDgi6g8Eq9j2jZii+xuBtuq pIKQ7GOXlMOTvoxh592aqF68mEQ21+vBh1az6Govpa2ykSPlo/WxlzdF3GCh1bU5Y80p +gsYNQqElvvoC0vehW2fpzVZLD6hRmjQYC/p9YaINacQocMe/cLrC/aYsgfcwvgTYObE tF4w== X-Forwarded-Encrypted: i=1; AJvYcCWBCjXT1MS2XD9ryueUOkMKBM7ndFVcpFEO7EgLR245z/sHt6zZ8N6GVgXSH5Nxh6ydDfN5H02C72WV@gnusha.org X-Gm-Message-State: AOJu0Yx76bSpNNJGRrcbF4VuzJC8CmxppxnfFcZpGFLZrTJkk9HDdTFG I5DUHOpvyjza+YACW8xRrIRICjp7RQ+08rpuEkU6TdBVFc1XkW56AXfv X-Google-Smtp-Source: AGHT+IFbwwFCMIMknfewPUpEhGGfC8eg5tTM+pgr+HUQ9eWnu9m4955KwxXatHXAMLTYbj00goKZsA== X-Received: by 2002:a05:6870:26d:b0:3e7:f3f0:a98 with SMTP id 586e51a60fabf-3e7f3f01530mr3658180fac.5.1762849715703; Tue, 11 Nov 2025 00:28:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aPx+yX2ZoAi7GhqaOu/cfr3UjFZal3wRqpLOmjSAl/ww==" Received: by 2002:a05:6870:9620:b0:3e2:d619:f0df with SMTP id 586e51a60fabf-3e2f1df712els3883158fac.0.-pod-prod-04-us; Tue, 11 Nov 2025 00:28:31 -0800 (PST) X-Received: by 2002:a05:6808:1b10:b0:441:ef6b:e690 with SMTP id 5614622812f47-4502a2e01a1mr6158068b6e.34.1762849710966; Tue, 11 Nov 2025 00:28:30 -0800 (PST) Received: by 2002:a05:690c:5c16:b0:780:f7eb:fdf with SMTP id 00721157ae682-786a51170c0ms7b3; Mon, 10 Nov 2025 23:43:10 -0800 (PST) X-Received: by 2002:a05:690e:158f:20b0:63f:b3b6:4654 with SMTP id 956f58d0204a3-640d45ceda5mr7459308d50.35.1762846990095; Mon, 10 Nov 2025 23:43:10 -0800 (PST) Date: Mon, 10 Nov 2025 23:43:09 -0800 (PST) From: "'Bitcoin Eagle' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <86d11552-36d8-46d7-998c-ed6875a5a84bn@googlegroups.com> In-Reply-To: <4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me> References: <4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_45602_1276729426.1762846989798" X-Original-Sender: hello@bitcoineagle.dev X-Original-From: Bitcoin Eagle Reply-To: Bitcoin Eagle 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 (-) ------=_Part_45602_1276729426.1762846989798 Content-Type: multipart/alternative; boundary="----=_Part_45603_298415382.1762846989798" ------=_Part_45603_298415382.1762846989798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Okay, if you or anyone can show me an example of a "boring and=20 unconcerning thing" that involves pre-signed transactions that use=20 deep/OP_IF-containing Taptrees and timelocks, which predates the original= =20 softfork proposal, I will be happy to update the BIP. Saying "someone might= =20 be doing this" is simply frivolous obstructionism which, again, could be=20 used to stop any attempt to change the consensus rules." If we skip the pontential strawman of presigned transaction let's describe= =20 realistic problem. 1. You have sensible multisig wallet which breaks one of the OP_IF or=20 merklepath restrictions. And you don't even know how it works inside. 2. To avoid confiscation you need to create a new wallet which is=20 designed in compliance with BIP444. Is there new miniscript compiler=20 available in time?=20 3. Migrate all UTXOs to new wallet 4. The real risk of confiscation are change addresses. After activation= =20 spending will work thanks to one time whitelist. But it creates a change= =20 which will be new UTXO unspendable On Monday, November 10, 2025 at 6:34:39=E2=80=AFAM UTC+7 dath...@proton.me = wrote: > Hi Greg - > > >It's not speculative-- nlocktime is a day one feature which *is* used in= =20 > Bitcoin. > > Correct, I have not claimed otherwise. > > >Sure someone could footgun themselves by intentionally using a=20 > transaction field which is expressly intended for forward compatibility a= nd=20 > get themselves burned-- but they'd have to be trying, not just doing a=20 > boring and unconcerning thing because those fields don't do anything so t= he=20 > only reason to use them would be an outright error or intentionally tryin= g=20 > to break themselves. > > Okay, if you or anyone can show me an example of a "boring and=20 > unconcerning thing" that involves pre-signed transactions that use=20 > deep/OP_IF-containing Taptrees and timelocks, which predates the original= =20 > softfork proposal, I will be happy to update the BIP. Saying "someone=20 > might be doing this" is simply frivolous obstructionism which, again, cou= ld=20 > be used to stop any attempt to change the consensus rules. > > >This is also not a new concern being raised for your proposal, every=20 > softfork post P2SH has been analyzed under this lens so it's quite=20 > 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= =20 > matter how pathological" has finally worn out. The longer we continue dow= n=20 > this path, the more likely it is that Bitcoin will become *entirely*=20 > pathological use cases. > > Accordingly, this BIP *intentionally* disrupts all of the most harmful=20 > use cases, because they are making Bitcoin worse money and the problem is= =20 > accelerating. But as stated before, the proposal also takes great pains n= ot=20 > to disrupt any non-pathological use cases, and again I'm open to revising= =20 > the spec if a concrete example that would be harmed by this softfork is= =20 > found. > > >And indeed I haven't read a new version because your prior message=20 > provided no reference to it > > It is attached as a file to my email. Does your email client not support= =20 > attachments? I'll be sure to include a browser-friendly link next time if= =20 > that'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= =20 > strictly-- this will absolutely confiscate funds as was pointed out and n= ot=20 > responded to even before your proposal. (because luke-jr proposed just th= at=20 > limit first-- actually a more relaxed version, then simply dishonestly=20 > insisted there was no opposition to it, even though opposition was=20 > immediately raised on the list). > > If you're referring to Andrew Poelstra's message here=20 > ,=20 > that doesn't strike me as "opposition", and besides, note that this=20 > proposal implements a very similar mitigation suggestion, which was: > > >In any case, if confiscation is a worry, as always we can exempt the=20 > current UTXO set from the rule -- if you are only spending outputs that= =20 > 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=20 > set, but does not allow such transactions to create outputs that violate= =20 > the new rules. This should be fine, since the funds can just be sent to a= =20 > different wallet, (assuming there is actually wallet software somewhere= =20 > that habitually creates outputs with scriptPubKeys larger than 34 bytes). > > Please let me know if this is not the "opposition" you were referring to;= =20 > I searched for a while but it's possible I missed something. Again, I am= =20 > eager to address all valid technical objections to this proposal, and so= =20 > far I haven't seen any. > > >I think your proposal continues to have no serious prospect of activatio= n > > I disagree. I think Bitcoin users are fed up with data spam and ready to= =20 > coordinate 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= =20 > whatever software they choose. > > >and its authors will likely find themselves mired in litigation by peopl= e=20 > harmed by it > > Just to clarify, are you saying that anyone who doesn't support the URSF= =20 > will face legal risks? > > >I think you'll find that almost every significant bitcoin developer will= =20 > stand against such a change and will not work on a fork that adopts them,= I=20 > also doubt the market would value your fork with such significant=20 > limitations very highly. > > I think you are mistaken. The Bitcoin community wants Bitcoin to be money= ,=20 > not data storage. > > Best, > > Dathon > On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell < > gmax...@gmail.com> wrote: > > It's not speculative-- nlocktime is a day one feature which *is* used in= =20 > Bitcoin. > > Sure someone could footgun themselves by intentionally using a transactio= n=20 > field which is expressly intended for forward compatibility and get=20 > themselves burned-- but they'd have to be trying, not just doing a boring= =20 > and unconcerning thing because those fields don't do anything so the only= =20 > reason to use them would be an outright error or intentionally trying to= =20 > break themselves. > > This is also not a new concern being raised for your proposal, every=20 > softfork post P2SH has been analyzed under this lens so it's quite=20 > concerning to see the proposal here simply ignore the concern. > > Even the intentional forward compat features have caused some lack of=20 > comfort in the past in this respect, which is why tapscript OP_SUCCESS=20 > works the way it does: so that any script that prematurely uses a 'succes= s'=20 > opcode would be inherently completely insecure-- an important improvement= =20 > in upgradability that your proposal permanently destroys without you even= =20 > understanding why it existed in the first place. > > And indeed I haven't read a new version because your prior message=20 > provided no reference to it-- it said you were requested to update the li= st=20 > and then you only provided a summary. I was responding to the summary. > > Now looking at it, I see that you are still limiting scriptpubkey sizes= =20 > strictly-- this will absolutely confiscate funds as was pointed out and n= ot=20 > responded to even before your proposal. (because luke-jr proposed just th= at=20 > limit first-- actually a more relaxed version, then simply dishonestly=20 > insisted there was no opposition to it, even though opposition was=20 > immediately raised on the list). > > I think your proposal continues to have no serious prospect of activation= ,=20 > and should it activate in any form it will just be forked against and its= =20 > authors will likely find themselves mired in litigation by people harmed = by=20 > it. I think you'll find that almost every significant bitcoin developer= =20 > will stand against such a change and will not work on a fork that adopts= =20 > them, I also doubt the market would value your fork with such significant= =20 > limitations 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 i= n=20 >> the restriction does reduce it), as there likely exist chains of not yet= =20 >> confirmed (and potentially timelocked) transactions that involve violati= ons=20 >> of this rule. Those would appear to the network to be outputs created at= a=20 >> later time, although they really weren't. It's unclear to me why you=20 >> haven't yet understood this point. >> >> While I completely agree that "confiscation" is a precedent we must avoi= d=20 >> setting, I think my proposal neither confiscates funds nor sets a bad=20 >> precedent, as it takes pains to avoid causing problems for all known use= =20 >> cases. I don't think it is reasonable never to create problems for all= =20 >> *unknown* use cases, as this would necessarily imply permanent=20 >> ossification. >> >> To illustrate the point: it is possible to design off-chain systems that= =20 >> "use" any given feature of the Bitcoin protocol, including, for example,= =20 >> OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfo= rk=20 >> proposal that redefines the OP_NOP. That is, anyone could intentionally= =20 >> lock funds into a pathological construction in order to obstruct any giv= en=20 >> softfork. >> >> Thus, if taken to the extreme, the argument that no one should ever have= =20 >> funds "confiscated", or even temporarily frozen, means that we can never= =20 >> upgrade Bitcoin again. So, in the interest of avoiding permanent=20 >> ossification, it seems wise for us to compromise somewhere in the middle= . I=20 >> think my proposal strikes a good balance. >> >> Of course, if people are reporting that there are known, non-pathologica= l=20 >> use cases with significant funds locked into pre-signed transactions, th= en=20 >> of course I will modify the proposal to accommodate them. >> >> >Another issue raised which you have not mentioned is that prior to you= =20 >> making this proposal I received minutes from a meeting which noted that= =20 >> Ocean Mining was the true author of this proposal and would be presentin= g=20 >> it under a false identity in order to conceal their involvement. Will yo= u=20 >> be correcting the record on the true authorship of this work and on whos= e=20 >> 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=20 >> mailing list and on the BIP PR, but both times my messages were suppress= ed=20 >> by moderators. >> >> I humbly request that moderators let the public see my response this=20 >> 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= =20 >> BIP was originally drafted by one of them), *I am not affiliated with=20 >> Ocean in any way*. I am just a Bitcoin dev who is concerned about the=20 >> 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=20 >> community*, because I and most Bitcoiners I know are concerned about=20 >> 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= ,=20 >> particularly with respect to concerns about potentially 'unlawful' mater= ial? >> >> No, I think this proposal is the best way to achieve its stated purpose,= =20 >> which is to reject the standardization of data storage as a supported us= e=20 >> case, at the consensus level. >> >> It sounds like you haven't read the new version of the BIP, nor my=20 >> summary above. I attached the document in my previous email message if y= ou=20 >> are interested. It removes all references to legal risks. >> >> For those who prefer viewing the proposal in a browser, I have pushed a= =20 >> copy of it to a non-PR branch, since the PR is still locked:=20 >> 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= =20 >> just as well be performed via a "less commonly abused" path? Would you a= lso=20 >> agree the same for essentially all other forms-- that they'd simply made= a=20 >> few line of code changes and then evade these restrictions? >> >> Again, this is no longer applicable to the proposal. The new draft makes= =20 >> significant changes. >> >> >In light of that, how would the very real and significant reductions in= =20 >> intentional functionality (such as efficient "few of dozens" multisigs o= r=20 >> other such constructs) be justified? How could the confiscation risk be= =20 >> justified? How could the deployment costs be justified? How could the=20 >> "policy risk" be justified? (E.g. that bitcoin could be driven or forced= in=20 >> to an endless sequences of 'update' blocking actions, each carrying its = own=20 >> risk and disruptions) >> >> I don't see this softfork as an "update-blocking action"; on the=20 >> contrary, I see it as an update-enabling one. As I stated previously,=20 >> attempting to never disrupt any use cases, no matter how pathological, i= s=20 >> the fastest path to ossification. >> >> Indeed, Bitcoin has failed to make any consensus upgrades at all since= =20 >> Taproot in 2021. The community has been going in circles now for two yea= rs=20 >> because of pathological use cases introduced by that fork, and this=20 >> proposal allows Bitcoiners to say "enough is enough", re-affirm that=20 >> Bitcoin is *money* rather than *data storage* by disabling all the most= =20 >> popular methods of data abuse, and move on to more exciting things. We= =20 >> could have new upgrades in one year if Bitcoiners focus on building them= =20 >> over the following months. >> >> I honestly don't see a better way out of this morass, but please let me= =20 >> 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= =20 >> having essentially zero risk of adoption, and if it were adopted (which = I=20 >> think is unlikely) >> >> I don't see much reason *not* to adopt it, besides fear of softforks in= =20 >> general, but I'm listening. >> >> >I think it's a certainty that there would be a countering fork to=20 >> continue a Bitcoin without these poorly justified (even essentially=20 >> useless) restrictions. >> >> I don't see why anyone in their right mind would choose to bet on the ol= d=20 >> fork where Bitcoin is filled with spam and confused about whether it mig= ht=20 >> 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 < >> gmax...@gmail.com> wrote: >> >> On Sat, Nov 8, 2025 at 12:58=E2=80=AFAM dathonohm via Bitcoin Developmen= t Mailing=20 >> List wrote: >> >>> >>> 1. "Funds confiscation": due to the presence of UTXOs that would be= =20 >>> made temporarily unspendable by this proposal, commenters were conce= rned=20 >>> that this would set a precedent of "confiscation". This new draft re= solves=20 >>> this concern by adding a UTXO height check to make sure *only UTXOs= =20 >>> that are created while the softfork is active will be made temporari= ly=20 >>> unspendable*. The "OP_IF in Tapscript" and "257-byte control block= =20 >>> limit" were the two main proposed rule changes that caused concern h= ere. >>> >>> >> That doesn't address the confiscation problem (although any reduction in= =20 >> the restriction does reduce it), as there likely exist chains of not yet= =20 >> confirmed (and potentially timelocked) transactions that involve violati= ons=20 >> of this rule. Those would appear to the network to be outputs created at= a=20 >> later time, although they really weren't. It's unclear to me why you=20 >> haven't yet understood this point. >> >> I don't think this concern was in any way limited to the control block o= f=20 >> op_if components either, essentially every aspect of the proposal has=20 >> confiscation issues. >> >> Another issue raised which you have not mentioned is that prior to you= =20 >> making this proposal I received minutes from a meeting which noted that= =20 >> Ocean Mining was the true author of this proposal and would be presentin= g=20 >> it under a false identity in order to conceal their involvement. Will yo= u=20 >> be correcting the record on the true authorship of this work and on whos= e=20 >> behalf its being performed? >> >> > "This doesn't block all possible methods of arbitrary data insertion":= =20 >> This was already addressed in the previous draft, but to reiterate: this= =20 >> proposal's goal is not to block *all* methods of arbitary data=20 >> insertion, just the most commonly abused ones. >> >> Would you then agree that this proposal will fail at its stated purpose,= =20 >> particularly with respect to concerns about potentially 'unlawful'=20 >> material? As that concern as expressed has a threshold of "any at all" a= nd=20 >> could just as well be performed via a "less commonly abused" path? Would= =20 >> you also agree the same for essentially all other forms-- that they'd=20 >> 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= =20 >> intentional functionality (such as efficient "few of dozens" multisigs o= r=20 >> other such constructs) be justified? How could the confiscation risk be= =20 >> justified? How could the deployment costs be justified? How could the=20 >> "policy risk" be justified? (E.g. that bitcoin could be driven or forced= in=20 >> to an endless sequences of 'update' blocking actions, each carrying its = own=20 >> risk and disruptions) >> >> Although your description of changes is vague and it's not possible to= =20 >> tell for sure without seeing the actual updates-- I don't think your=20 >> suggested revisions will move your proposal off from having essentially= =20 >> zero risk of adoption, and if it were adopted (which I think is unlikely= ) I=20 >> think it's a certainty that there would be a countering fork to continue= a=20 >> Bitcoin without these poorly justified (even essentially useless)=20 >> restrictions. >> >> >> >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5H= gxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com >> . >> >> >> --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSoj= T530Uwzi0b3sOG0%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/= 86d11552-36d8-46d7-998c-ed6875a5a84bn%40googlegroups.com. ------=_Part_45603_298415382.1762846989798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Okay,= if you or anyone can show me an example of a "boring and unconcerning thin= g" that involves=C2=A0pre-signed transactions that use deep/OP_IF-containi= ng Taptrees and timelocks,=C2=A0which predates the original softfork propos= al, I will be happy to update the BIP. Saying "someone might be doing this"= is simply frivolous obstructionism which, again, could be used to stop any= attempt to change the consensus rules."

If we skip the pontential strawman of presigned= transaction let's describe realistic problem.
  1. You have sensible multisig = wallet which breaks one of the OP_IF or merklepath restrictions. And you do= n't even know how it works inside.
  2. To avoid confiscation you need to create a new wa= llet which is designed in compliance with BIP444. Is there new miniscript c= ompiler available in time?=C2=A0
  3. Migrate all UTXOs to new wallet
  4. The real risk of confiscatio= n are change addresses. After activation spending will work thanks to one t= ime whitelist. But it creates a change which will be new UTXO unspendable

On Monday, November 10, 2025 at 6:34:39=E2=80=AFAM UTC+7 = dath...@proton.me wrote:
Hi Greg -

>I= t's not speculative-- nlocktime is a day one feature which *is* used in= Bitcoin.

Correct, I have not claimed otherwise.

>S= ure someone could footgun themselves by intentionally using a transaction f= ield which is expressly intended for forward compatibility and get themselv= es burned-- but they'd have to be trying, not just doing a boring and u= nconcerning thing because those fields don't do anything so the only re= ason to use them would be an outright error or intentionally trying to brea= k themselves.

Okay, if you or anyone can show me an example of a= "boring and unconcerning thing" that involves=C2=A0pre-sig= ned transactions that use deep/OP_IF-containing Taptrees and timelocks,=C2= =A0which predates the original softfork proposal, I will be ha= ppy 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.

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

I believe t= he utility of the strategy of "don't break any use cases, no matte= r how pathological" has finally worn out. The longer we continue down = this path, the more likely it is that Bitcoin will become entirely p= athological use cases.

Accordingly, this BIP=C2=A0intentionall= y disrupts all of the most harmful use cases, because they are making B= itcoin worse money and the problem is accelerating. But as stated before, t= he 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 th= at would be harmed by this softfork is found.

>And indeed I ha= ven't read a new version because your prior message provided no referen= ce to it

It is attached as a file to my email. Does your email cl= ient not support attachments? I'll be sure to include a browser-friendl= y link next time if that's the case.

>I was responding to = the summary.

The summary mentioned that I had removed all refer= ences to legal risks.

>Now looking at it, I see that you are s= till limiting scriptpubkey sizes strictly-- 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 ve= rsion, then simply dishonestly insisted there was no opposition to it, even= though opposition was immediately raised on the list).

If you= 9;re referring to Andrew Poelstra's message here, that doesn= 't strike me as "opposition", and besides, note that this pro= posal 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 inputs that spend from the cu= rrent UTXO set, but does not allow such transactions to create outputs that= violate the new rules. This should be fine, since the funds can just be se= nt to a different wallet, (assuming there is actually wallet software somew= here that habitually creates outputs with scriptPubKeys larger than 34 byte= s).

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

>I think yo= ur proposal continues to have no serious prospect of activation

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

>should it activa= te in any form it will just be forked against

That would be incre= dibly risky, but of 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 sayin= g that anyone who doesn't support the URSF will face legal risks?
=

>I think you'll find that almost every significant bitcoin deve= loper will stand against such a change and will not work on a fork that ado= pts them, I also doubt the market would value your fork with such significa= nt limitations 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 <gmax...@gmail.com> 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 transaction field= which is expressly intended for forward compatibility and get themselves b= urned-- but they'd have to be trying, not just doing a boring and uncon= cerning 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 th= emselves.

This is also not a new concern bein= g raised for your proposal, every softfork post P2SH has been analyzed under this lens so it's quit= e 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 'suc= cess' opcode would be inherently completely insecure-- an important imp= rovement in upgradability that your proposal permanently destroys without y= ou even understanding why it existed in the first place.

And indeed I haven't read a new version because your prior messa= ge provided no reference to it-- it said you were requested to update the l= ist and then you only provided a summary. I was responding to the summary.<= /div>

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).

I thi= nk your proposal continues to have no serious prospect of activation, and s= hould it activate in any form it will just be forked against and its author= s will likely find themselves mired in litigation by people harmed by it. = I think you'll find that almost every significant bitcoin developer wil= l stand 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 limita= tions very highly.


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

>That= doesn't address the confiscation problem (although any reduction in th= e restriction does reduce it), as there likely exist chains of not yet conf= irmed (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 setting, I think= my proposal neither confiscates funds nor sets a bad precedent, as it take= s pains to avoid causing problems for all known use cases. I don't thin= k it is reasonable never to create problems for all unknown use case= s, as this would necessarily imply permanent ossification.

To il= lustrate the point: it is possible to design off-chain systems that "u= se" any given feature of the Bitcoin protocol, including, for example,= OP_NOPs. Funds locked in such UTXOs would be "confiscated" by th= e softfork proposal that redefines the OP_NOP. That is, anyone could intent= ionally lock funds into a pathological construction in order to obstruct an= y given softfork.

Thus, if taken to the extreme, the argument tha= t no one should ever have funds "confiscated", or even temporaril= y frozen, means that we can never upgrade Bitcoin again. So, in the interes= t of avoiding permanent ossification, it seems wise for us to compromise so= mewhere in the middle. I think my proposal strikes a good balance.


>A= nother issue raised which you have not mentioned is that prior to you makin= g this proposal I received minutes from a meeting which noted that Ocean Mi= ning 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 correc= ting 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 f= alse rumors.

I already attempted to correct the record on this,= both here on this mailing list and on the BIP PR, but both times my messag= es were suppressed by moderators.
<= br>
I humbly request that moderator= s 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 communic= ation with some Ocean employees (and the BIP was originally drafted by one = of them), I am not affiliated with Ocean in any way. I am = just a Bitcoin dev who is concerned about the implications of Core 30 havin= g been released and gaining adoption.

I am acting solely on my= own behalf and on the behalf of the Bitcoin community, because I and m= ost Bitcoiners I know are concerned about Bitcoin's future if it embrac= es 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, particularly= with respect to concerns about potentially 'unlawful' material?

No, I think this proposal is the best way to achieve its stated pur= pose, 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 summary above. I attached the docu= ment in my previous email message if you are interested. It removes all ref= erences to legal risks.

<= div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);b= ackground-color:rgb(255,255,255)">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/b= lob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki

>A= s that concern as expressed has a threshold of "any at all" and c= ould just as well be performed via a "less commonly abused" path?= Would you also agree the same for essentially all other forms-- that they&= #39;d simply made a few line of code changes and then evade these restricti= ons?

Again, this is no longer applicable to the proposal. The new= draft makes significant changes.
<= br>
>In light of that, how would= the very real and significant reductions in intentional functionality (suc= h as efficient "few of dozens" multisigs or other such constructs= ) be justified? How could the confiscation risk be justified? How could th= e deployment costs be justified? How could the "policy risk" be = justified? (E.g. that bitcoin could be driven or forced in to an endless se= quences of 'update' blocking actions, each carrying its own risk an= d disruptions)

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

Indeed, = Bitcoin has failed to make any consensus upgrades at all since Taproot in 2= 021. The community has been going in circles now for two years because of p= athological use cases introduced by that fork, and this proposal allows Bit= coiners to say "enough is enough", re-affirm that Bitcoin is m= oney rather than data storage by disabling all the most popular = methods of data abuse, and move on to more exciting things. We could have n= ew upgrades in one year if Bitcoiners focus on building them over the follo= wing 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 rev= isions will move your proposal off from having essentially zero risk of ado= ption, 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 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) restrictions.

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


Dathon
On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmax...@gmail.com<= /a>> wrote:
  1. "Funds confiscation": due to the presence of UTXOs that = would be made temporarily unspendable by this proposal, commenters were con= cerned that this would set a precedent of "confiscation". This ne= w draft 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 temp= orarily unspendable. The "OP_IF in Tapscript" and "257-b= yte control 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= 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 wh= y 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 confisc= ation 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 pr= oposal and would be presenting it under a false identity in order to concea= l their involvement. Will you be correcting the record on the true authors= hip of this work and on whose behalf its being performed?

> "This doesn't block all possible methods of arb= itrary data insertion": This was already addressed in the previous draft, but to 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? As that concern as expressed h= as a threshold of "any at all" and could just as well be performe= d via a "less commonly abused" path? Would you also agree the sa= me 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 s= ignificant 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 b= e justified? How could the "policy risk" be justified? (E.g. tha= t bitcoin could be driven or forced in to an endless sequences of 'upda= te' 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 y= our proposal off from having essentially zero risk of adoption, and if it w= ere adopted (which I think is unlikely) I think it's a certainty that t= here would be a countering fork to continue a Bitcoin without these poorly = justified (even essentially useless) restrictions.
<= br>




--
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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid= /bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-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 bitc= oindev+...@googlegroups.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/bitcoind= ev/86d11552-36d8-46d7-998c-ed6875a5a84bn%40googlegroups.com.
------=_Part_45603_298415382.1762846989798-- ------=_Part_45602_1276729426.1762846989798--