[BIP Proposal] Reduced Data Temporary Softfork

[dath...@proton.me]

Hi list -

Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr's ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections:

https://github.com/bitcoin/bips/pull/2017

The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage. It is implemented as a temporary softfork that can activate in one of two different ways: proactive, or reactive.

After a year, the soft fork expires, giving us time to come up with a more permanent solution.

The timeline is a bit tight, but I think everyone has incentives to support a quick and orderly activation.

Please feel free to leave a comment on the PR or reach out to me over email with any feedback. 

There is much work still to do, so if you have some technical skills and would like to join in the effort with dev/testing, please reach out as well.

Bitcoin is money.

Sincerely,

Dathon Ohm

[Jameson Lopp]

It's quite clear from the PR discussion that there are a multitude of contentious issues at play with this proposal.

Even aside from all of the technical concerns, the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks makes it a non-starter in my opinion.

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me.

[Peter Todd]

On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote:
> Hi list -
>

> Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on [luke-jr's ML proposal](https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections:
>
> https://github.com/bitcoin/bips/pull/2017

Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
contains the full text of this BIP as of writing(1), while simultaneously being
compliant with that BIP.

Clearly, this approach is ineffective.

1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[dath...@proton.me]

Peter -

Thank you for demonstrating what non-contiguous data looks like.

I trust you when you say that you can parse the BIP's contents from this transaction, but all it looks like to me (and the Bitcoin network) is a UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length OP_RETURN, sending all ~100 USD in fees to the miner.

Since legally hazardous content can be generated from any input data, including your 30-input consolidation transaction (as long as the correct third-party program is used), it would not make sense to hold node operators legally responsible for storing and distributing such input data.

However, if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. In that case, node operators could conceivably be held responsible for possession and distribution.

Since arbitrary data storage does nothing to benefit Bitcoin as permissionless money, there is no good reason to force this additional legal risk on node operators, who already face enough challenges as it is.

Best,

Dathon

On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org> wrote:

> On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote:
>
> > Hi list -
> >

> > Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr's ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections:

> >
> > https://github.com/bitcoin/bips/pull/2017
>
>
> Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
> contains the full text of this BIP as of writing(1), while simultaneously being
> compliant with that BIP.
>
> Clearly, this approach is ineffective.
>
> 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org.

[dath...@proton.me]

Jameson -

You mention "technical concerns" but don't give any examples. Would you mind sharing one?

You also mention "the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks", but I don't think the BIP implies this at all.

The BIP merely highlights a legal risk Bitcoin Core 30 has created for node operators for no good reason, and attempts to eliminate it. No "coercion" is implied. You and anyone else who are fine shouldering this risk are free to stay on the old data-friendly chain. I doubt you will have much company, though.

Best,

Dathon

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.com.

[TheWrlck]

I’m not convinced that restricting or discouraging non-transactional data is the right approach. While limiting data size may reduce certain abuses, it also constrains legitimate use cases that leverage Bitcoin’s data-carrying capabilities (e.g. commitments, metadata, or novel protocols). From a consensus-layer perspective, Bitcoin should remain neutral about how data is interpreted or used, as long as it follows the defined rules and pays the required fees. Imposing normative judgments about "spam" risks introducing subjective policy where objective validation should suffice.

[Jameson Lopp]

On Mon, Oct 27, 2025 at 12:22 AM <dath...@proton.me> wrote:

Jameson -

You mention "technical concerns" but don't give any examples. Would you mind sharing one?

Two of the biggest technical concerns are that the proposed changes are confiscatory for certain scripts and the fact that the reactive chain reorganization logic actually makes it possible for anyone to trivially double spend their coins by triggering a reorganization.

 

You also mention "the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks", but I don't think the BIP implies this at all.

I quote the BIP:

"rejecting this softfork may subject you to legal or moral consequences"

This vague, hand waving fear mongering is the underlying implication of legal coercion to which I referred. It's not appropriate for a technical specification.

[Jal Toorey]

"bitcoin is money"

The definition of what is money is extremely subjective.  The history of it shows this (not the history saifedean paints). Trying to direct the development to capture a definition of money opens a huge attack vector. It's not different than trying to decide what is spam. 

Also what is the difference between the bashers slogan that bitcoin is p2p money and "bitcoin is money"  They seem like the same thing? 

[Kyle Stout]

Dathon,

> if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content.

This seems to be the crux of your argument. I believe it is misleading and technically unsound. It's technical theater that creates a distinction without any meaningful difference.

First, Bitcoin has no concept of a file viewer. To interpret any embedded data other to validate it against Bitcoin's rules, you must use a third party tool. Practically speaking, the differences are negligible in terms of technical difficulty, as humorously demonstrated here: https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, you're file carving. 

Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin since it has no native concept of 'image', 'video', etc. Arbitrary bytes are meaningless. The purpose of having OP_RETURN as a standard output is to protect the UTXO set from being abused. It isn't some kind of 'blessing' to store files. That's absurd. As you admit, it's impossible to stop people from writing arbitrary bytes to the blockchain, so this is damage mitigation, not an invitation.

Third, contiguity is not a legally meaningful predicate. "Your honor, we tried to limit the contiguous bytes!" is simply not going to fly. The bytes exist either way, and they must be interpreted by third party software either way. If anything, this path is going to represent a voluntary self-policing that will result in more culpability. Right now, arbitrary bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes relay opaque protocol data. If you insist on only accepting 'approved' arbitrary bytes, you're opening the door to a knowledge/intent accusation.

Regards,

Kyle

[Greg Maxwell]

The only consensus normative data encoding in Bitcoin is the order data goes into hashes.  The representations in memory, rpc, in the p2p network, etc. are already different and could be made arbitrarily different without any consensus change.  Case in point:  the data is now normally encrypted on disk and in P2P.  There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki  none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory).

Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are.

If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish.  Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone.

Good news for everyone except those who consider coercing others to be a terminal goal. 

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com.

[dath...@proton.me]

Hi list -

Thanks for all of the feedback everyone!

I am working on a new draft of the BIP that will hopefully address everyone's concerns and avoid the misunderstandings that have arisen.

I apologize for not being able to respond to all of you, but know that I did indeed read your messages.

Best,

Dathon

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com.

[Antoine Riard]

Hi Dathon Ohm,

I did a cursory review of your BIP proposal, not on the technical matter as there
is no reference implementation available, but I did one on the legalities raised
in the text (grep'ing the word "legal" one can find 15 references versus only 2
references to the word "technical").

Under European law, there is a clearly established line of jurisprudences exonerating
internet service providers or hosting operators to have to install a system for
filtering all electronic communications passing via its services which would
apply indiscriminately to all its users for any kind of content (CJUE, 24-11-2011,
aff C-70/10 Scarlet Extended SA c/ SABAM, CJUE, 16-02-2012, aff C-260/10 SABAM c/ Netlog).
Rather to engage in generic filtering on the burden of services providers, courts
have generally yielded decisions asking for fine-grained deletion of a specific content,
as a safeguard of other interest at stake, notably users's right to privacy [0].

Further, in the eventuality of an extended filtering system would have to be put
in place by a service provider, and if said filtering system design would be unable
to dissociate between legal content and illegal content, the introduction of this
filtering system would consistute an infringement of the freedom of expression and
information (CJUE, 26-04-2022, aff C‑401/19). Those judicial decisions are litteraly
encompassing peer-to-peer softwares in their scope, as somehow before Bitcoin, they
was something called Bittorent.

Moreover, this line of jurisprudence underlights that any interference with one's
fundamental right of expression should be lay down under clear and precise rules
governing the scope of the interference. This is not a mere formality, as again
and again too restrictives measures are strike down (CEDH, 02-02-2016, Index.hu/Hungary,
aff. n° 22947/13). As far as I know, I'm not aware of any European continental
country that has made a legislation on how one is allowed to use his right to
the freedom of expression in the context of publishing stuff in a Bitcoin block.

Under the US law, I won't risk making legal comment for now, as for anyone who is
following the work of the Electronic Frontier Foundation from times to times, there
is a pending case in front of the US Supreme Court, Cox Communications, Inc vs. Sony
Music Entertainment specifically on the liability of Internet service providers. But
culturally the US are even more protective on the freedom of expression, which puts
an even higher legal bar for any restriction of it.

I concur with Gregory Maxwell. There is zero need to change the consensus rules.

In the idea one would like to limit one's responsability arising from how bitcoin
consensus data can be encoded or decoded to "obviously" "illegal" content (as strictly
defined by a specific national legislation) [1], fuzzy encoders and decoders for
end-to-end or point-to-point communication could be formalized as BIP documents,
that would put an asymmetric cost on the decoders, with the upper bound being the
impossibility of decoding.

Fuzzy algorithms is not sci-fi tech it's actually what is used for Minisketch.

Best,
Antoine
OTS hash: f0e10776d4e4d32873ca319daf3b76c8e645a0d510a6bb803bb8685292c119d4

[0] "Those addresses are protected personal data because they allow those users to be precisely identified"
[1] This is not a mere technicality, under information theory, one could come up with
a alphanumeric encoding algorithm that could certainly yield text-based religious blaspheme
in a lot of countries in the world from years-old un-reorgable historical blockchain data.
We're all used to "The Times 03 Jan..." in the genesis block, but it's just picking hex
as a decoding algorithm...

[/dev /fd0]

Hi Greg,

> There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki  none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory).

[Compression][0] of raw transactions is interesting although it won't be helpful in this case. I had reviewed the pull request that implemented BIP 337 in bitcoin core and was closed. Maybe we can add it in knots.

> Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are.

> If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish.  Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone.

I am not sure if encoding or encryption would be the right approach but this is worth trying. I have opened an [issue][1] in knots repository to discuss these ideas and also created a web [page][2] that shows the binary for OP_RETURN in a transaction. 

[0[: https://github.com/bitcoin/bitcoin/pull/29134
[1]: https://github.com/bitcoinknots/bitcoin/issues/229
[2]: https://opreturn01.github.io/

/dev/fd0

floppy disk guy

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com.

[Max]

Why don't we just quickly soft fork to disallow large OP_RETURN outputs (i.e. keep them capped to 80 bytes) only, with forward-looking activation (no retroactive block invalidation)? This would give the market a clear and simple way to decide whether such transactions are acceptable or not. It wouldn't have any of the issues mentioned so far in the discussion like creating an incentive to put CSAM or other illegal content to attempt a reorg double spend due to the complex deployment mechanism proposed in BIP-444 or like putting in jeopardy existing Taproot functionality by touching other primitives. We don't actually need to remove all the mechanisms that can be used for embedding data (which has been demonstrated to be impossible). Rather what we need is to give users the opportunity to signal whether arbitrary data is welcome or not.

If the legal concerns are compelling enough to warrant consensus changes, miners should support a clean soft fork immediately. If the market quickly adopts the new consensus-level OP_RETURN restrictions it would announce sufficiently clearly to the world that arbitrary data is not welcome and deter future attempts to bring that to Bitcoin by showing the network's readiness to resist such efforts. I believe that this PR is too dramatic and needlessly complicated for what we need: letting the market decide whether to accept or reject the explicit invitation for arbitrary data storage that Core v30 has created. Technical changes should be limited to this question only and simple enough for people to make a decision without being distracted or overwhelmed by adjacent issues.

[Erik Aronesty]

Case law in the USA regarding illegal content has always rested squarely on those who:

 1 - provide broad public access, in this case a company like OpenSEA (which has had to block content)
 2 - the original author 

if punishing "relays" was a thing, then every CISCO router, SMTP relay and DISCORD server that provided access would be in court all day long

instead, it's the users of the illegal data and the publishers that actually wind up in trouble - not the internet providers

the bitcoin ledger is neither a browser or web server, nor is it an image uploader.  there is zero ability to view images built into the system

and even if it was

the purpose of this software is to be a distributed and effectively uncensorable ledger. 

hopefully it doesn't change because someone launched a meme campaign with vague threats of legal action

if a transaction has /no reasonable expectation of being mined/ (too expensive to validate, too large, too low fees), there's also no reason to relay it

this is probably the best way to set policy

[dath...@proton.me]

Hi all -

BIP repo maintainers requested that I update this list before pushing a significant change, so I am doing that now.

Please consider this my formal request for the BIP PR to be unlocked so that discussion can resume.

This update addresses several concerns from the previous draft:

1. "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO 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.
2. "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.
3. "Blocks other softfork upgrades while active": This was also addressed in the original draft, but to reiterate: it's unlikely that any softfork upgrades will be ready to activate within one year anyway, so this doesn't matter much. But also, the fact that this softfork expires creates an opportunity to activate a more permanent and elegant upgrade that turns on what the community wants, while continuing to reject data storage as a supported use case, after one year.
4. "Reactive deployment risks": These concerns have been addressed by removing the reactive deployment method entirely. I still think activating this softfork is a matter of some urgency, but I think it still achieves its goals if we move steadily towards activation within a few months.
5. "Missing code": The code is now public here: https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please note that, while there are references to "BIP-444" in the code, that is just a placeholder and I will update it to whatever number the BIP editors decide).
6. "Temporary expiry risks": "Requires another consensus change before expiry or rules lapse": Yes, as stated in <3>, the community will have to come together in a year either to extend these rules (which shouldn't be difficult), or to activate something more permanent and less blunt. The expiry will not be a hardfork, contrary to some claims I've seen, because opting into this deployment means opting into the expiry as well, so old nodes will follow new ones onto the unrestricted chain
7. "Legal/process/conflict-of-interest concerns": all language about legal risks has been stripped from the BIP.

I welcome any and all feedback, as I think this proposal or something similar to it stands an excellent chance of gaining consensus and activating, and I think if that happens, it could be curative for the Bitcoin community.

Thanks again for all of your feedback and support, it means a lot.

Sincerely,

Dathon

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.com.

[Edil Guimarães de Medeiros]

1. "Missing code": The code is now public here: https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please note that, while there are references to "BIP-444" in the code, that is just a placeholder and I will update it to whatever number the BIP editors decide).

Wanted to have a glimpse at the code, but it looks like this repo doesn't build on top of eeb9cc1120661d0e9fd28ddb6fef2c04992a4666 which I understand is the knots release in which this is supposed to be based considering the name of the branch.

So, I have no idea how one can review this (under the assumption that they reviewed or trusts the Knots release).

BTW, I only noted now that commits on the Knots repo (and thus this) have no signatures other than Core devs' or Datonohm's (an account that was created 2 weeks ago?).

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc%3D%40proton.me.

--

Edil

[Bitcoin Eagle]

ad 1) Funds confiscation: as already mentioned by gmaxwell there is a risk of confiscation of presigned transactions. Lightning like protocols that simulate covenants using n-of-n multisig. Will be confiscated even if UTXO height is whitelisted

[Greg Maxwell]

On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:

1. "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO 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.

[Daniel Buchner]

I agree with Greg, 0 quantification of what defines success has been provided for the generally expressed intention of reducing spam. If one admits any decentralized system that allows user-derived public keys / hashes fundamentally includes the ability to embed spurious data in place of those values, eliminating the spamming of those values is effectively impossible. That leaves us with the question: given the goal is simply 'reduction of spam', what defines success and what are the limiting principles? If success is 'reduce spam as much as possible', that would implicitly mean one should remove virtually all OP codes and leave Bitcoin with only basic send/receive that utilizes as few public keys and hashes as possible. Through this rational, empirical lens, I just don't see how this PR's seemingly arbitrary modifications of Bitcoin's protocol rules 1) actually reduce spam (likely will just result in spammers using different constructions), and 2) achieve mitigation of the hazy legal concerns that were a primary driver of this initiative.

Can you please quantify what amounts/measurables you are targeting, and explain why this PR will achieve reductions to those level, such that they deliver on desired outcomes? Please connect whatever realistically achievable level reductions you believe will occur to the real world effects you believe they will deliver, such as "If we can just ensure no block can contain more than X bytes of spam, the Three-Letter Agency Y will not come after us because Z rule/limit/law/regulation says so". I am just providing an example of linking action to outcome delivery, so if you don't like that one, please provide whatever you feel best conveys it.

[Chris Riley]

Hi,

From what I have read so far there is not a clear, quantifiable, agreed-upon set of criteria defining what constitutes “spam.”  Some describe it as a "large non-monetary data embedded in transactions" but what counts as large?  Are lightning HTLCs (etc.) "monetary" or are they merely monetary adjacent?  What specifically defines "non-monetary"?  I've also seen things like “undesirable extra load” or “not following best practices” but again what qualifies as "undesirable"  and what is "best practices"?  Ideally, I'd like to see something that says: "a transaction is spam if it meets criteria X, Y, and Z."

In my view, the inability to create a precise, objective definition makes such rules essentially impossible to specify or enforce consistently, leading to endless whack-a-mole changes. That in turn highlights why this proposal seems problematic: any attempt to codify “spam” without a rigorous definition risks both social and technical fragmentation — continual revisions under external pressures, and a probable fork if implemented. 

Have a nice weekend,

Chris

--

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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com.

[dath...@proton.me]

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

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com.

[Greg Maxwell]

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.