Zac Greenwood [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-24 📝 Original message:Reducing the footprint of ...
📅 Original date posted:2022-02-24
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/da19f3fb/attachment.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/da19f3fb/attachment.html>;