On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss <k98kurz@gmail.com> wrote:

It seems to me that most participants in the current debate/controversy agree (or at least once previously agreed) with the premise that using the Bitcoin network for storing non-monetary data is an unintended use case for the Bitcoin protocol.

I believe that is fair.

The community is split between those who want to do something to mitigate the harm of stuffing arbitrary data into non-provably unspendable taproot outputs and those who do not want to engage in the caching in-mempool and promulgation of non-monetary data.

Do you mean "and those who *do* want to engage in caching ..."? If so, I think this misses the point somewhat. My view isn't that I *want* (or want others) to cache/relay non-financial transactions. It's that I believe that intentionally instituting or maintaining a relay policy that does not match what is making it reliably into blocks anyway is both:

largely ineffective (because people can create software with other policies, or submit directly to miners)
harmful on itself (because it slows down block propagation, breaks various DoS protections in relay by being unable to reason about what is likely to be confirmed, hurts fee estimation, and makes it more profitable for miners to offer private submission which if widely adopted would hurt the ability for smaller miners to enter the market).

While the benefit, even if effective, is minimal: blocks are reliably full, and were reliably full long before data-storage schemes became popular, thus nodes are processing the same amount of data anyway. In fact, nodes with policies that diverge from block content will process more data, as to them, blocks will contain more unexpected transactions that they still have to process anyway.

My dislike for non-financial use is/was twofold, and neither case is really aided by diverging relay policies today:

Often a bad fit for the technology, chosen because of ease of design ("just dump your backups on chain"), but would due to inefficiency of the design by priced out sooner or later anyway. This was far more an issue when demand for block space was low, and blocks were not reliably full. And this was also where the existing OP_RETURN policies originated: as a way to discourage building solutions that used the very cheap block space at the time, as it wouldn't last anyway. This is far less a concern today, because block space prices are higher, and more alternatively and more appropriate technologies are commonplace.
Because it's a use case driven by collateral hype ("NFTs on Bitcoin!") which I feel are dumb, and perhaps hurts Bitcoin's reputation by association with it. However, I very much believe - and hope - Bitcoin can be used effectively for things I (or you, or others) do not approve of. Censorship resistance is the entire point of the design, and it cuts both ways.

Perhaps this was all clear, and your statement was just aiming to be brief, but I wanted to make sure you're not misinterpreting the view as *liking* non-financial transactions.

There is nothing in the Bitcoin protocol to incentivize or compensate node operators for storing and relaying this data, so to align incentives, I propose adding a configurable data blob relay service to the Bitcoin network protocol with the following properties:

I think you are under the mistaken impression that the disagreement is about what set of transactions should be acceptable on the network, and then crafting a policy that matches that.

To me (and this is just my impression, I don't want to speak for anyone else) the core dispute is about whether a diverging relay policy, even if just mildly effective in discouraging use cases, is beneficial or harmful to the network. What you're suggesting is instituting even more policy, which is an even larger burden to comply with than what exists today, even if it somehow expands what use cases are permitted. To me, that is worse than doing nothing, as it'll even more effectively encourage people to bypass any software implementing such policies, whether that is by the development of even easier and cheaper ways to submit directly to miners, or by incentivizing the development or promotion of software that doesn't have these policies.

What do y'all think? Would such a system even be worth pursuing conceptually as part of a compromise to resolve this debate?

I do not consider this to be a compromise at all. It is embracing the failed notion that policy should only relay transactions that people like.

Pieter