OP_RETURN limit softfork bip

cgilliard commented at 7:00 am on April 16, 2021: contributor

notarization 77d9d9c8ef

Update bip-XXXX.mediawiki 9f61db119a

benthecarman commented at 9:18 pm on April 18, 2021: contributor

NACK, I see no purpose to this. OP_RETURNs do not take up much chain space currently and this will make it harder for things like Open timestamps to exist

junderw commented at 10:17 pm on April 18, 2021: contributor

NACK

This requires a hard fork. So no.
Limiting OP_RETURNs based on transaction count is not helpful, since the OP_RETURN size limit is a standardization rule only, so a miner could easily add 4M WU of OP_RETURN data in one tx if they wanted… so this BIP doesn’t solve much.
The whole reason why OP_RETURNs were allowed to begin with was a compromise to prevent protocols using dummy pubkeys etc. to embed information. If OP_RETURN were limited in this way, they will just move back to hiding the data, making it harder to prune later on.
In general, limiting anything by transaction count in the consensus layer is problematic, because the whole point of blocks are to create transaction ordering, and by limiting any type of transaction to a single tx creates problems with ordering. Increasing risk of front-running those transactions for whatever reason. Since we can’t be sure of the true meaning of any transaction (even a simple p2pkh) we should try not to add any consensus rule that increases that risk.

in bip-XXXX.mediawiki:20 in 9f61db119a outdated

15+
16+This BIP proposes limiting the number of transactions which contain an OP_RETURN opcode to one per block.
17+
18+==Motivation==
19+
20+For background, the OP_RETURN opcode [<a href="#references">1</a>], 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 [<a href="#references">2</a>] 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.

luke-jr commented at 2:21 am on April 25, 2021:

Note: 80 bytes is a particular node-fiat policy, not part of the Bitcoin consensus system.

in bip-XXXX.mediawiki:24 in 9f61db119a outdated

19+
20+For background, the OP_RETURN opcode [<a href="#references">1</a>], 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 [<a href="#references">2</a>] 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.
21+
22+==Specification==
23+
24+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.

luke-jr commented at 2:23 am on April 25, 2021:

What if scripts wish to use OP_RETURN conditionally for some programmic purpose? (Not required to fix for BIP assignment/merge, just something IMO should be clarified)

cgilliard commented at 4:18 am on April 25, 2021:

Do you know of any examples of this? What would the use case be?

luke-jr commented at 10:12 pm on April 25, 2021:

Nothing comes to mind immediately, but presumably it would be handy within an OP_IF block.

luke-jr changes_requested

luke-jr commented at 2:23 am on April 25, 2021: member

If you still wish to move forward with this BIP, please fix the backward compatibility section: I do not see anything that makes this a hardfork (meaning, old nodes will reject new blocks).

luke-jr added the label New BIP on Apr 25, 2021

Update bip-XXXX.mediawiki d806c76bad

cgilliard commented at 4:17 am on April 25, 2021: contributor

If you still wish to move forward with this BIP, please fix the backward compatibility section: I do not see anything that makes this a hardfork (meaning, old nodes will reject new blocks).

Done.

gmaxwell commented at 8:03 pm on April 25, 2021: contributor

@cgilliard It would be a kindness to the community for you to abandon this proposal. I think the response makes it unambiguous that a proposal like this won’t be adopted by essentially anyone. It’s better to preserve the bips list for proposals that are going to make progress.

in bip-XXXX.mediawiki:53 in d806c76bad

48+
49+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.
50+
51+==Compatibility==
52+
53+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.

luke-jr commented at 10:21 pm on April 25, 2021:

IMO this should really talk about interaction with BIPs 47, 141, and ideally 300, 301, and other such hypothetical possible future improvements.

luke-jr renamed this:
~~OP_RETURN limit hard fork bip~~
OP_RETURN limit softfork bip
on Apr 25, 2021

luke-jr commented at 10:23 pm on April 25, 2021: member

This has technically met the requirements for a BIP number assignment. Can you explicitly confirm you want one?

Personally, I tend to agree with @gmaxwell that this is probably a dead end proposal. (And if you do move forward with it anyway, I hope you address my other comments too)

cgilliard commented at 1:54 am on April 26, 2021: contributor

@gmaxwell @luke-jr, Ok, I don’t want to cause any hassle so I will close the pull request.

cgilliard closed this on Apr 26, 2021

OP_RETURN limit softfork bip #1105