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


On Thu, 24 Feb 2022 at 10:19, vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>