Date: Fri, 25 Feb 2022 03:19:34 +0000
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com>
In-Reply-To: <CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet>
 <CAJ4-pEBnprd-SdXMZeDsJ37=SiGbQEnaFfpvBzryR21Wbqc1Ew@mail.gmail.com>
 <vmZt7irtItdhrsha-cHM0-HgzhCQ6GlWdJXr6mKzEHXmoNz5ypuQLR9eKsltreHb0O2kMfcr_VRkZ1hmoJ9RAp5DaMZorhG1JsRSclhin6s=@protonmail.com>
 <CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Precedence: list

Good morning Zac,

> Hi=C2=A0ZmnSCPxj,
>
> Any benefits of my proposal depend on my presumption that using a standar=
d transaction for storing data must be inefficient. Presumably a transactio=
n takes up significantly more on-chain space than the data it carries withi=
n its OP_RETURN. Therefore, not requiring a standard transaction for data s=
torage should be more efficient. Facilitating data storage within some spec=
ialized, more space-efficient data structure at marginally lower fee per pa=
yload-byte should enable reducing the footprint of storing data on-chain.
>
> In case storing data through OP_RETURN embedded within a transaction is o=
ptimal in terms of on-chain footprint then my proposal doesn=E2=80=99t seem=
 useful.

You need to have some assurance that, if you pay a fee, this data gets on t=
he 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 y=
ou have to provably authorize the spend of that UTXO.
But that is already an existing transaction structure, the transaction inpu=
t.
If you are not going to pay an entire UTXO for it, you need a transaction o=
utput as well to store the change.

Your signature needs to cover the data being published, and it is more effi=
cient to have a single signature that covers the transaction input, the tra=
nsaction 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 th=
ere, 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 variabl=
e-size we do need an equivalent to the `OP_PUSH` opcode (which has many var=
iants depending on the size of the data).

But that is not really a lot of bytes, and adding a separate field to the t=
ransaction would require a hardfork.
We cannot use the SegWit technique of just adding a new field that is not s=
erialized 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 softfork=
able, but the technique does not apply here.
The reason we cannot use that technique is that we want to save bytes by ha=
ving the signature cover the data to be published, and signatures need to b=
e 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 mor=
e actual bytes to save a few bytes.

Saving a few bytes for an application that is arguably not the "job" of Bit=
coin (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