Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH



Summary:

The discussion on the best way to publish data in post-taproot bitcoin has been ongoing. One option is using OP_RETURN, which allows for immediate visibility of published data in the blockchain. This method is considered better for time-stamping. Another option is Taproot, where spending the UTXO makes the script visible. This method is better when data doesn't need to be immediately public but requires future revelation. For smaller amounts of data (80 bytes or less), OP_RETURN is still preferred unless it's essential to reveal later. The conversation continues with various proposals being put forward. Christopher Allen says he doesn't have a concrete proposal in mind, but he wants to understand the tradeoffs better in post-taproot bitcoin. In response to a proposal that uses OP_PUSH and OP_DROP, Peter Todd asks why not OpPush OpDrop instead. Allen responds by saying he doesn't have a preference for either and saw the proposal recently. Todd also clarifies that it's incorrect to say that OpReturn outputs "clog UTXO space" because the whole point of OpReturn is to standardize a way to keep such outputs out of the UTXO set. There are also OP_RETURN tricks in production that do clog UTXO space. Allen chose 64 bytes to illustrate an example that could be a signature, two hashes, a hash plus some metadata, etc. He notes that almost every op_return live out there is >32 bytes, so he wanted something larger. Finally, Allen asks what the most pragmatic way is to publish data in the bitcoin blockchain while minimizing potential harm. The answer pre-taproot was OP_RETURN, but they're exploring options for post-taproot bitcoin.


Updated on: 2023-06-16T04:12:35.405566+00:00