Subject: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy

From: Jonathan Voss <[email-masked]>
Date: Sat, 24 May 2025 14:07:17 -0700 (PDT)

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. The original compromise was to place a hash within an 
OP_RETURN so that people could commit to some data using the "distributed 
timestamp server" in a way that could be dropped from the UTXO set. 
Promulgation of the data so committed was left as an exercise for the 
person using OP_RETURN, and some use cases (e.g. OpenTimestamps) do not 
require it. However, the recent discussion premised upon Citrea's 
Clementine Bridge evidences primarily that the relaying capabilities of the 
Bitcoin network itself are sufficiently useful for L2 designers that there 
is an incentive to bypass standardness restrictions for the sake of 
reliably promulgating data -- at least in the case of Citrea, they say they 
need to quickly and widely disseminate 140+ bytes of arbitrary ZKP data to 
recover from an invalid protocol state, and the utility of that ZKP data 
very quickly decreases after it has been confirmed and processed. 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.

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:
1) Each blob relayed must have a sha256 (or double sha256, whichever is 
easier to implement) matching an OP_RETURN output contained within a valid 
txn in the mempool.
2) Each blob relayed must have a length of X bytes or less (default of 1 KB 
to comfortably sit within most MTUs). Optionally, blobs above this size 
could require an additional burn fee, or this could be uncapped.
3) The relevant txn in the mempool must contain a single OP_RETURN with 
exactly the bytes 0xFFFFFFFFFFFFFFFF followed by the blob hash.
4) The relevant txn in the mempool must burn sats at a configurable rate of 
sats/100 bytes of blob size + a rate of sats per txn output by assigning 
those sats to the OP_RETURN output. (Defaults should be something low like 
20 and 50, respectively.)
5) The relevant txn in the mempool must pay a fee rate of at least the 
average fee rate of the previous 10 blocks. If that average fee rate rises 
before the txn is confirmed, the blob can be dropped from the cache or 
given a higher probability of being pruned.

The data blob will then be cached on nodes and remain there as long as the 
relevant txn  is still valid according to the above rules and has not been 
confirmed by more than 5 blocks. Thereafter, the probability it is dropped 
from the cache will be semi-proportional to the inverse of the burned fee 
rate: sort blobs by ascending number of confirmations and descending burn 
rate, then pop from the list and drop from the cache until the cache size 
limit is reached. (Cache size limit will be configurable, with a default of 
1 GB.)

The burning of sats compensates node operators through deflation (assuming 
that most node operators own bitcoins), aligning the incentives. The 
minimum fee rate requirement prevents data blobs from sticking around in 
perpetuity for transactions that are unlikely to be included in blocks, 
also incentivizing miners to mine these transactions quickly enough that 
the data can be dropped from the relay cache reasonably quickly. If 
necessary, probabilistic sharding could be accomplished during the cache 
pruning phase using rendezvous hashing to create an additional sorting 
metric that sorts all matching blobs to the front of the list or applies a 
modifier to another sorting metric; i.e. rendezvous hash hit results in a 
lower index thus reducing the likelihood of the blob being dropped.

Then merge the data carrier style changes from Luke-jr to filter 
inscription reveal transactions to disincentivize misusing the blockchain 
for replicating ephemeral data. By providing a reliable relay mechanism, 
anyone who previously used inscriptions can adapt their protocol to 
indefinitely store the arbitrary data relayed by the network and just point 
at the OP_RETURN to prove the data commitment made it onto the Bitcoin 
blockchain or re-broadcast the blob in a new compliant txn. The 
inscription+ordinals system can then be adapted accordingly since it is a 
contrived system anyway: either require the committed data to specify the 
index of the output to inscribe + the inscribed data, or just assign it to 
the first sat of the first non-OP_RETURN output.

This relay policy upgrade would require at a minimum a new feature bit flag 
in the version message, a new inv_vector type, and a new message type. A 
high-bandwidth mode optimization could be to transmit the txn and matching 
blob in a single new message type, but having nodes request the blob after 
parsing a valid txn for this system would probably be sufficient. All 
parameters can be tweaked, but I think the concept is reasonably solid.

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

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com.