Date: Fri, 25 Feb 2022 12:48:11 +0000
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <JGiZgKJbF8rNYsQfjHNeqRqRUyfUuGaP0_W7Y9-uyyhDF0odqoF3dPitBwe7uXmhUh8TcwFOYGymzrgMhc2Kgq9NovHQSf_d0jRsDFH3zuk=@protonmail.com>
In-Reply-To: <CAJ4-pEDAKPFQF-tuzYw+Hc0moViZ4kyoVz91mESkqb-GQZ35aQ@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>
 <XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com>
 <CAJ4-pEDAKPFQF-tuzYw+Hc0moViZ4kyoVz91mESkqb-GQZ35aQ@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 ZmnSCPxj,
>
> To me it seems that more space can be saved.
>
> The data-=E2=80=9Ctransaction=E2=80=9D need not specify any output. The n=
etwork could subtract the fee amount of the transaction directly from the s=
pecified UTXO.

That is not how UTXO systems like Bitcoin work.
Either you consume the entire UTXO (take away the "U" from the "UTXO") comp=
letely and in full, or you do not touch the UTXO (and cannot get fees from =
it).

> A fee also need not to be specified.

Fees are never explicit in Bitcoin; it is always the difference between tot=
al input amount minus the total output amount.

> It can be calculated in advance both by the network and the transaction s=
ender based on the size of the data.

It is already implicitly calculated by the difference between the total inp=
ut amount minus the total output amount.

You seem to misunderstand as well.
Fee rate is computed from the fee (computed from total input minus total ou=
tput) divided by the transaction weight.
Nodes do not compute fees from feerate and weight.

> The calculation of the fee should be such that it only marginally cheaper=
 to use this new construct over using one or more transactions. For instanc=
e, sending 81 bytes should cost as much as two OP_RETURN transactions (minu=
s some marginal discount to incentivize the use of this more efficient way =
to store data).

Do you want to change weight calculations?
*reducing* weight calculations is a hardfork, increasing it is a softfork.

> If the balance of the selected UTXO is insufficient to pay for the data t=
hen the transaction will be invalid.
>
> I can=E2=80=99t judge whether this particular approach would require a ha=
rdfork, sadly.

See above note, if you want to somehow reduce the weight of the data so as =
to reduce the cost of data relative to `OP_RETURN`, that is a hardfork.

Regards,
ZmnSCPxj