* [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
@ 2025-05-24 21:07 Jonathan Voss
0 siblings, 0 replies; only message in thread
From: Jonathan Voss @ 2025-05-24 21:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5806 bytes --]
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6221 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2025-05-24 21:34 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-24 21:07 [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox