From: dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Erik Aronesty <erik@q32.com>,
Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sun, 09 Nov 2025 20:07:08 +0000 [thread overview]
Message-ID: <4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me> (raw)
In-Reply-To: <CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0+VZEcaAw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 17874 bytes --]
Hi Greg -
>It's not speculative-- nlocktime is a day one feature which *is* used in Bitcoin.
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 themselves burned-- 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.
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-containing Taptrees and timelocks, which predates the original softfork proposal, 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.
>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.
I believe the utility of the strategy of "don't break any use cases, no matter how pathological" has finally worn out. The longer we continue down this path, the more likely it is that Bitcoin will become entirely pathological 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 because your prior message provided no reference to it
It is attached as a file to my email. Does your email client not support attachments? I'll be sure to include a browser-friendly link next time if 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 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 version, then simply dishonestly insisted 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.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/4KvpvYNEAgAJ), 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.
The current proposal exempts inputs that spend from the current 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 sent to a different wallet, (assuming there is actually wallet software somewhere that habitually 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 eager 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 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 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 URSF will face legal risks?
>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 the market would value your fork with such significant 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 <gmaxwell@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 burned-- 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.
>
> And 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 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 version, then simply dishonestly insisted 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 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 the market would value your fork with such significant limitations very highly.
>
> On Sat, Nov 8, 2025 at 9:02 PM <dathonohm@proton.me> 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 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.
>>
>> 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 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 "use" any given feature of the Bitcoin protocol, including, for example, OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork proposal that redefines the OP_NOP. That is, anyone could intentionally lock funds into a pathological construction in order to obstruct any given softfork.
>>
>> 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 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-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 mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed?
>>
>> It sounds like you have fallen victim to some false 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 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:
>>
>> 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 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 community, 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 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 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 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: 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 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?
>>
>> 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 other such constructs) be justified? How could the confiscation risk be justified? How could the deployment costs be justified? How could the "policy risk" be justified? (E.g. that bitcoin could be driven or forced in to an endless sequences of 'update' blocking actions, each carrying its own risk and disruptions)
>>
>> 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 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 for 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 the 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 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 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 fork where Bitcoin is filled with spam and confused about whether it might 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 <gmaxwell@gmail.com> wrote:
>>
>>> On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
>>>
>>>> - "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 height check to make sure only UTXOs that are created while the softfork is active will be made temporarily unspendable. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern 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 violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point.
>>>
>>> I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues.
>>>
>>> Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed?
>>>
>>>> "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of arbitary data insertion, just the most commonly abused ones.
>>>
>>> Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? As that concern as expressed has a threshold of "any at all" and could just as well be performed via a "less commonly abused" path? Would you also agree the same for essentially all other forms-- that they'd simply made a few line of code changes and then evade these restrictions?
>>>
>>> In light of that, how would the very real and significant reductions in intentional functionality (such as efficient "few of dozens" multisigs or other such constructs) be justified? How could the confiscation risk be justified? How could the deployment costs be justified? How could the "policy risk" be justified? (E.g. that bitcoin could be driven or forced in to an endless sequences of 'update' blocking actions, each carrying its own risk and disruptions)
>>>
>>> Although your description of changes is vague and it's not possible to tell for sure without seeing the actual updates-- I don't think your suggested revisions will move your proposal off from having essentially zero risk of adoption, and if it were adopted (which I think is unlikely) I think it's a certainty that there would be a countering fork to continue a Bitcoin without these poorly justified (even essentially useless) restrictions.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-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 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY%3D%40proton.me.
[-- Attachment #2: Type: text/html, Size: 33909 bytes --]
next prev parent reply other threads:[~2025-11-09 23:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros
2025-11-08 9:30 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-08 15:38 ` Greg Maxwell
2025-11-08 16:40 ` Daniel Buchner
2025-11-08 17:55 ` Chris Riley
2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 21:39 ` Greg Maxwell
2025-11-09 20:07 ` dathonohm via Bitcoin Development Mailing List [this message]
2025-11-11 7:43 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-11 16:23 ` Greg Maxwell
2025-11-09 1:21 ` Murch
2025-11-09 20:56 ` onyxcoyote
2025-11-09 21:34 ` Peter Todd
2025-11-10 19:46 ` Lucas Barbosa
2025-10-28 9:16 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=antoine.riard@gmail.com \
--cc=dathonohm@proton.me \
--cc=erik@q32.com \
--cc=gmaxwell@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox