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.