Reducing the footprint of storing data on-chain might better be achieved by *supporting* it.
Currently storing data is wasteful because it is embedded inside an OP_RETURN within a transaction structure. As an alternative, by supporting storing of raw data without creating a transaction, waste can be reduced.
Storing data in this way must only be marginally cheaper per on-chain byte than the current method using OP_RETURN by applying the appropriate weight-per-byte for on-chain data.
The intended result is a smaller footprint for on-chain data without making it cheaper (except marginally in order to disincentivize the use of OP_RETURN).
Zac
Since Taproot was activated, we no longer need separate OP_RETURN outputs to be pushed on-chain. If we want to attach any data to a transaction, we can create "OP_RETURN <anything>" as a branch in the TapScript. In this way, we can store that data off-chain and we can always prove that they are connected with some taproot address, that was pushed on-chain. Also, we can store more than 80 bytes for "free", because no such taproot branch will be ever pushed on-chain and used as an input. That means we can use "OP_RETURN <1.5 GB of data>", create some address having that taproot branch, and later prove to anyone that such "1.5 GB of data" is connected with our taproot address.
Currently in Bitcoin Core we have "data" field in "createrawtransaction". Should the implementation be changed to place that data in a TapScript instead of creating separate OP_RETURN output? What do you think?
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev