Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-17 🗒️ Summary of this message: Using witness ...
📅 Original date posted:2023-02-17
🗒️ Summary of this message: Using witness data can be cheaper than using OP_RETURN output for publishing data, especially for data larger than 140 bytes.
📝 Original message:On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.
Given today's standardness constraints, that's true (because you first
need to construct a p2wsh/tapscript output that commits to the data,
then you have to spend it), but it needn't stay that way. Allowing a data
carrier entry in the annex (as contemplated for eltoo [0]) would allow
you to publish the data with a single transaction, with malleability
prevented because the annex content is committed to by the signature.
[0] https://github.com/bitcoin-inquisition/bitcoin/pull/22
I think the cost for publishing data via the witness today is roughly:
115 vb - for the commitment tx
115 vb + datalen/4 - for the publication tx
versus
125 vb + datalen - for a tx with an OP_RETURN output
so the crossover point is at a datalen of about 140 bytes. Perhaps
slightly more or less depending on how much you can combine these
inputs/outputs with other txs you would have made anyway.
With a datacarrier in the annex that has similar or higher limits than
OP_RETURN, I don't think OP_RETURN would ever be cheaper.
The other advantage to using the witness for random data compared to
OP_RETURN is that the txid commits to OP_RETURN output, so you must
download all OP_RETURN data to validate a block's merkle tree, whereas
you can partially validate a block (in particular, you can validate the
spendable utxo set) without downloading witness data [1].
[1] https://github.com/bitcoin/bitcoin/pull/27050
Cheers,
aj
🗒️ Summary of this message: Using witness data can be cheaper than using OP_RETURN output for publishing data, especially for data larger than 140 bytes.
📝 Original message:On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.
Given today's standardness constraints, that's true (because you first
need to construct a p2wsh/tapscript output that commits to the data,
then you have to spend it), but it needn't stay that way. Allowing a data
carrier entry in the annex (as contemplated for eltoo [0]) would allow
you to publish the data with a single transaction, with malleability
prevented because the annex content is committed to by the signature.
[0] https://github.com/bitcoin-inquisition/bitcoin/pull/22
I think the cost for publishing data via the witness today is roughly:
115 vb - for the commitment tx
115 vb + datalen/4 - for the publication tx
versus
125 vb + datalen - for a tx with an OP_RETURN output
so the crossover point is at a datalen of about 140 bytes. Perhaps
slightly more or less depending on how much you can combine these
inputs/outputs with other txs you would have made anyway.
With a datacarrier in the annex that has similar or higher limits than
OP_RETURN, I don't think OP_RETURN would ever be cheaper.
The other advantage to using the witness for random data compared to
OP_RETURN is that the txid commits to OP_RETURN output, so you must
download all OP_RETURN data to validate a block's merkle tree, whereas
you can partially validate a block (in particular, you can validate the
spendable utxo set) without downloading witness data [1].
[1] https://github.com/bitcoin/bitcoin/pull/27050
Cheers,
aj