pull down to refresh

210 sats \ 1 reply \ @Murch 6 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
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.
write
preview
23 sats \ 0 replies \ @hgw39 7 May
Thanks Murch.
reply