Posted by Jonathan Voss
May 24, 2025/21:07 UTC
The ongoing debate within the Bitcoin community centers around the use of the Bitcoin network for storing non-monetary data, which many believe was not an intended use case of the Bitcoin protocol. The discussion has been particularly ignited by Citrea's Clementine Bridge, which highlights the need for a reliable method to disseminate arbitrary data, in their case, Zero-Knowledge Proof (ZKP) data critical for maintaining protocol integrity. This situation underlines the utility of the Bitcoin network beyond simple monetary transactions, prompting a division among community members on how to address the incorporation of non-monetary data within Bitcoin transactions.
To align incentives and manage the relay of non-monetary data effectively, a proposal has been put forward to introduce a configurable data blob relay service into the Bitcoin network protocol. This service would have specific requirements: each blob must match a sha256 hash contained within an OP_RETURN output of a valid transaction in the mempool, be of a certain length, and the transaction must adhere to particular conditions including burning Satoshi’s (sats) at a rate based on the blob size and paying a fee rate that matches or exceeds the average of the previous 10 blocks. These measures aim to compensate node operators through deflation, given that they are assumed to own bitcoins, and ensure that data does not remain indefinitely, thus preventing clogging.
Moreover, the proposal outlines mechanisms for caching and pruning data blobs based on confirmation numbers and the burned fee rate, with a caching limit suggested at 1 GB. It also suggests incorporating methods to disincentivize the misuse of the blockchain for ephemeral data replication. By establishing a reliable relay mechanism, protocols relying on the transmission of arbitrary data can adapt to store this data off-chain while using the OP_RETURN hash as proof of commitment on the blockchain.
This relay policy upgrade would necessitate technical adjustments, including new feature flags and message types, to facilitate efficient data transmission and retrieval. The concept aims to offer a middle ground in the current debate by providing a structured way to handle non-monetary data transmissions within the Bitcoin network, potentially resolving the ongoing controversy regarding its usage scope.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback