BIP: XXXX Layer: Consensus (soft fork) Title: Limit number of transactions which contain an OP_RETURN opcode to one per block Author: Christopher Gilliard <christopher.gilliard@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX Status: Draft Type: Standards Track Created: 2021-04-16 License: BSD-2-Clause
This BIP proposes limiting the number of transactions which contain an OP_RETURN opcode to one per block.
For background, the OP_RETURN opcode [1], is used in Bitcoin to store arbitrary additional data into a block which is then permanently stored as part of the blockchain. Today there is a limitation of one OP_RETURN per transaction and each OP_RETURN is limited to 80 bytes of data. With very limited block space, it is essential to optimize the data stored in a block. Since a Merkle Tree [2] or other similar data structures can be used to timestamp multiple documents by storing a single 32 byte checksum of the top of a Merkle Tree in a block, there is no reason to allow more than one OP_RETURN per block. If only a single OP_RETURN is allowed, per block, users will be required to coordinate in order to store individual checksums into this data structure, but this can be achieved by developing a layer two time-stamping protocol. This layer two time-stamping protocol will allow users to store thousands or even millions of checksums into a single block and at the same time limit the total amount of data in the block to 80 bytes. A future BIP proposing such a layer two protocol will be forthcoming. Use cases other than time-stamping will be harder to achieve with this proposal, and that is part of the goal of this BIP since those other use cases should be discouraged by the rules of the protocol.
After deployment (see the Deployment section for details), blocks that contain more than one OP_RETURN opcode will be rejected by full nodes. Additionally, new logic will be needed for the transaction pool because miners must select a single OP_RETURN transaction to include in the block. Ultimately, miners will run a different piece of code that builds the tree structure required to timestamp data and include their own OP_RETURN transaction in blocks they mine. A future BIP outlining the layer two protocol will describe an incentive structure so that miners will benefit from building the trees in the layer two protocol. The entire tree will be downloadable via a decentralized storage mechanism that will be described in a forthcoming BIP as well.
Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is TBD.
Activation is achieved when 900 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, fifth, sixth, and thirtieth bits set (0x20000037 in hex). The activation time will be the timestamp of the 900'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade.
At the end of the activation period, which will last for 6 months, there will be a mandatory activation flag day similar to BIP 148.
Test network parameters are the same as the main network, except starting earlier with easier supermajority conditions and a shorter grace period:
starting time: TBD
activation condition: 90 of 100 blocks
grace period: 24 hours
mandatory activation flag date: TBD
Time-stamping, or notarization, is an important use of Bitcoin and, importantly, it is a direct use which is essential for a good money. Optimizing the way Bitcoin stores notarization data is important. It is also important to enforce rules that require users to coordinate in a reasonable manner for the good of the community. This will lower transaction fees for all users and even lower transaction fees for users who wish to timestamp their own data. Miners will be incentivized by layer two protocol rewards. See [3] for further discussion on the rationale.
The main objection to this proposal will be the risk and effort required to execute a soft fork. It is important to note that other soft fork proposals may be incorporated into this proposal or this proposal may be incorporated into other proposals which mitigates this risk if the value of all the proposed fork features exceeds the costs. An additional objection may be that current applications make use of the OP_RETURN field and upgrading them will add cost. While this is true, the design of those applications was not optimal and this upgrade is needed. In the long run, it will reduce the running costs of those applications and optimize the use of block-space.
As a soft fork, older software will continue to operate without modification, but miners will need to upgrade before the soft fork activates. Additionally users using the OP_RETURN opcode will likely need to update their software to make use of a layer two standard instead of using OP_RETURN directly.
TBD
[1] - https://en.bitcoin.it/wiki/OP_RETURN
[2] - https://en.wikipedia.org/wiki/Merkle_tree
[3] - https://chrisgilliard.medium.com/notarization-good-money-and-a-proposal-for-bitcoin-ac3585756bee