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.