pull down to refresh

431 sats \ 3 replies \ @Murch 4 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
There are currently three ways of embedding data in the Bitcoin blockchain in use.
  1. Inscriptions are written to an unexecuted branch of a taproot leaf script. This data appears in the witness stack of inputs. Witness data is only validated once when a node first validates a transaction’s scripts and is stored as part of the full blockchain record. When a pruning node performs IBD using the assumevalid option, witness data doesn’t have to be downloaded or evaluated at all. Witness data is discounted by 75% compared to other transaction data, but is malleable until a transaction is confirmed.
  2. OP_RETURN data appears in the output script. OP_RETURN outputs are only validated once when the node first sees the transaction. The data in output scripts is not discounted and not malleable, as signatures on the inputs generally commit to the exact output scripts. As OP_RETURN outputs are unspendable, they are stored as part of the transaction in the blockchain data, but do not get added to the UTXO set.
  3. Some schemes (e.g., Stamps) embed data in payment output scripts using either fake public keys or fake hashes. The data for output scripts is not discounted. As these output scripts are not clearly unspendable, these output scripts must be retained in the UTXO set.
Citrea recently announced that they plan to write data to payment outputs because they need non-malleable transaction data that gets confirmed timely in excess of the current OP_RETURN standardness limit. As the use of payment output scripts cannot be easily prevented, encouraging them to use OP_RETURN outputs instead would be harm reduction as at least the data would not be written to the UTXO set that every node has to retain forever.
The proponents in the mailing list thread and pull request further argue that it is more expensive to write large data payloads to OP_RETURN outputs than inscriptions and therefore use cases that already use inscriptions are not incentivized to use OP_RETURN. The break-even point for that appears to be 143 bytes above which payloads are more expensive to be embedded into OP_RETURN outputs.
I am not aware of any effects on LN development.
write
preview
63 sats \ 2 replies \ @hgw39 6 May
Hi Murch. Your answers here have really helped me understand more about OP_RETURNs in general, and this issue, so thanks. Here are my questions. Given the 3 ways data can be embedded in the blockchain, how effective against each of these methods are the actions proposed in the PR? My understandings are:
  1. Writing data to a taproot leaf script. Lifting the OP_RETURN limit will not provide an attractive alternative for people embedding data, for any data above 143 bytes. So not effective against most arbitrary data.
  2. Data in the output script using the OP_RETURN op code. Lifting the limit seeks to encourage more data to be embedded using OP_RETURNs, as the current limit may prevent some data from being propagated around the network as it becomes non standard. (But can be worked around by going to a miner out of band)
  3. Embedding data using fake public keys or hashes. Does raising the OP_RETURN limit offer an incentive for this kind of embedded data? Does it become cheaper using OP_RETURN or not?
I'm trying to focus on the logic and incentives of the proposal, not the emotion and blah blah.
And one final question, why is this company Citrea being cited so much in this PR and discussion? I see Core Devs linking to their Whitepaper in the PR and I wonder why a single company's use case and requirements are being considered to heavily in this discussion. Shouldn't that be a non factor for a Bitcoin Core PR?
Anyway, thanks for helping out with these questions.
reply
210 sats \ 1 reply \ @Murch 6 May
You are welcome, thank you for taking the time to read my comments.
  1. Writing data to a taproot leaf script. Lifting the OP_RETURN limit will not provide an attractive alternative for people embedding data, for any data above 143 bytes. So not effective against most arbitrary data.
  2. Data in the output script using the OP_RETURN op code. Lifting the limit seeks to encourage more data to be embedded using OP_RETURNs, as the current limit may prevent some data from being propagated around the network as it becomes non standard. (But can be worked around by going to a miner out of band)
I would perhaps quibble with "seeks to encourage", but overall we agree.
  1. Embedding data using fake public keys or hashes. Does raising the OP_RETURN limit offer an incentive for this kind of embedded data? Does it become cheaper using OP_RETURN or not?
Yes, a data payload embedded per OP_RETURN would be cheaper than fake public keys or pubkey hashes. I calculate that it would save at least 5–10 bytes of overhead for a small data payload, and much more for larger data payloads.
And one final question, why is this company Citrea being cited so much in this PR and discussion? I see Core Devs linking to their Whitepaper in the PR and I wonder why a single company's use case and requirements are being considered to heavily in this discussion. Shouldn't that be a non factor for a Bitcoin Core PR?
My read is that Citrea provides a concrete example of detrimental behavior that could be mitigated by raising the OP_RETURN limit. Since there is a concrete description of their scheme it makes an easy to communicate example.
reply
23 sats \ 0 replies \ @hgw39 7 May
Thanks Murch.
reply