From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Zac Greenwood <zachgrw@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Date: Fri, 25 Feb 2022 03:19:34 +0000 [thread overview]
Message-ID: <XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com> (raw)
In-Reply-To: <CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
Good morning Zac,
> Hi ZmnSCPxj,
>
> Any benefits of my proposal depend on my presumption that using a standard transaction for storing data must be inefficient. Presumably a transaction takes up significantly more on-chain space than the data it carries within its OP_RETURN. Therefore, not requiring a standard transaction for data storage should be more efficient. Facilitating data storage within some specialized, more space-efficient data structure at marginally lower fee per payload-byte should enable reducing the footprint of storing data on-chain.
>
> In case storing data through OP_RETURN embedded within a transaction is optimal in terms of on-chain footprint then my proposal doesn’t seem useful.
You need to have some assurance that, if you pay a fee, this data gets on the blockchain.
And you also need to pay a fee for the blockchain space.
In order to do that, you need to indicate an existing UTXO, and of course you have to provably authorize the spend of that UTXO.
But that is already an existing transaction structure, the transaction input.
If you are not going to pay an entire UTXO for it, you need a transaction output as well to store the change.
Your signature needs to cover the data being published, and it is more efficient to have a single signature that covers the transaction input, the transaction output, and the data being published.
We already have a structure for that, the transaction.
So an `OP_RETURN` transaction output is added and you put published data there, and existing constructions make everything Just Work (TM).
Now I admit we can shave off some bytes.
Pure published data does not need an amount, and using a transaction output means there is always an amount field.
We do not want the `OP_RETURN` opcode itself, though if the data is variable-size we do need an equivalent to the `OP_PUSH` opcode (which has many variants depending on the size of the data).
But that is not really a lot of bytes, and adding a separate field to the transaction would require a hardfork.
We cannot use the SegWit technique of just adding a new field that is not serialized for `txid` and `wtxid` calculations, but is committed in a new id, let us call it `dtxid`, and a new Merkle Tree added to the coinbase.
If we *could*, then a separate field for data publication would be softforkable, but the technique does not apply here.
The reason we cannot use that technique is that we want to save bytes by having the signature cover the data to be published, and signatures need to be validated by pre-softfork nodes looking at just the data committed to in `wtxid`.
If you have a separate signature that is in the `dtxid`, then you spend more actual bytes to save a few bytes.
Saving a few bytes for an application that is arguably not the "job" of Bitcoin (Bitcoin is supposed to be for value transfer, not data archiving) is not enough to justify a **hard**fork.
And any softfork seems likely to spend more bytes than what it could save.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-02-25 3:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 9:02 vjudeu
2022-02-24 10:08 ` Ruben Somsen
2022-02-24 13:27 ` vjudeu
2022-02-24 14:01 ` Ruben Somsen
2022-02-24 21:40 ` Zac Greenwood
2022-02-25 0:04 ` ZmnSCPxj
2022-02-25 1:12 ` Zac Greenwood
2022-02-25 3:19 ` ZmnSCPxj [this message]
2022-02-25 7:15 ` Zac Greenwood
2022-02-25 12:48 ` ZmnSCPxj
2022-02-25 13:53 ` Zac Greenwood
2022-03-16 18:21 ` Peter Todd
2022-03-19 18:32 ` vjudeu
2022-03-21 11:00 ` Kostas Karasavvas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=zachgrw@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox