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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
