Hi Jonathan,
On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss <k98k...@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
--
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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net.
