MIME-Version: 1.0
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>
 <JGiZgKJbF8rNYsQfjHNeqRqRUyfUuGaP0_W7Y9-uyyhDF0odqoF3dPitBwe7uXmhUh8TcwFOYGymzrgMhc2Kgq9NovHQSf_d0jRsDFH3zuk=@protonmail.com>
In-Reply-To: <JGiZgKJbF8rNYsQfjHNeqRqRUyfUuGaP0_W7Y9-uyyhDF0odqoF3dPitBwe7uXmhUh8TcwFOYGymzrgMhc2Kgq9NovHQSf_d0jRsDFH3zuk=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Fri, 25 Feb 2022 14:53:57 +0100
Message-ID: <CAJ4-pEBpGiXi9paON50o91fyqDw+s9RPy8_e6AH6HSbdWU4i_g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000060df3505d8d808d5"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Precedence: list

--00000000000060df3505d8d808d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

> Either you consume the entire UTXO (take away the "U" from the "UTXO")
completely and in full, or you do not touch the UTXO

Ok, so enabling spending a UTXO partly would be a significant departure
from the systems=E2=80=99 design philosophy.

I have been unclear about the fee part. In my proposal there=E2=80=99s only=
 one
input and zero outputs, so normally there would be no way to set any fee.
One could add a fee field although that would be slightly wasteful =E2=80=
=94 it may
be sufficient to just specify the fee *rate*, for instance 0-255
sat/payload_byte, requiring only one byte for the fee. The calculation of
the actual fee can be performed by both the network and the sender. The fee
equals payload_size*feerate +
an-amount-calculated-by-preset-rules-such-that-it-raises-the-cost-of-the-tr=
ansaction-to-only-marginally-less-than-what-it
would-have-cost-to-store-the-same-amount-of-data-using-one-or-more-OP_RETUR=
N-transactions.

However explicitly specifying the fee amount is probably preferable for the
sake of transparency.

I wonder if this proposal could technically work. I fully recognize though
that even if it would, it has close to zero chances becoming reality as it
breaks the core design based on *U*TXOs (and likely also a lot of existing
software) =E2=80=94 thank you for pointing that out and for your helpful fe=
edback.

Zac


On Fri, 25 Feb 2022 at 13:48, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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=
 network could
> subtract the fee amount of the transaction directly from the specified UT=
XO.
>
> That is not how UTXO systems like Bitcoin work.
> Either you consume the entire UTXO (take away the "U" from the "UTXO")
> completely 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
> total input amount minus the total output amount.
>
> > It can be calculated in advance both by the network and the transaction
> sender based on the size of the data.
>
> It is already implicitly calculated by the difference between the total
> input 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
> output) 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. Fo=
r
> instance, sending 81 bytes should cost as much as two OP_RETURN
> transactions (minus 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
> then the transaction will be invalid.
> >
> > I can=E2=80=99t judge whether this particular approach would require a =
hardfork,
> sadly.
>
> See above note, if you want to somehow reduce the weight of the data so a=
s
> to reduce the cost of data relative to `OP_RETURN`, that is a hardfork.
>
> Regards,
> ZmnSCPxj
>

--00000000000060df3505d8d808d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><span style=3D"border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,2=
04,204);color:rgb(0,0,0)">Hi ZmnSCPxj,</span><br></div><div><span style=3D"=
border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,=
0,0)"><br></span></div><div dir=3D"auto"><span style=3D"border-color:rgb(0,=
0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)">&gt;</span><s=
pan style=3D"color:rgb(0,0,0)">=C2=A0Either you consume the entire UTXO (ta=
ke away the &quot;U&quot; from the &quot;UTXO&quot;) completely and in full=
, or you do not touch the UTXO</span></div><div dir=3D"auto"><span style=3D=
"color:rgb(0,0,0)"><br></span></div><div style=3D"background-color:rgba(0,0=
,0,0)!important;border-color:rgb(255,255,255)!important;color:rgb(255,255,2=
55)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Ok, so enablin=
g spending a UTXO partly would be a significant departure from the systems=
=E2=80=99 design philosophy.</font></div><div><span style=3D"border-color:r=
gb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><br></sp=
an></div><div dir=3D"auto"><span style=3D"border-color:rgb(0,0,0) rgb(0,0,0=
) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)">I have been unclear about t=
he fee part. In my proposal there=E2=80=99s only one input and zero outputs=
, so normally there would be no way to set any fee. One could add a fee fie=
ld although that would be slightly wasteful =E2=80=94 it may be sufficient =
to just specify the fee *rate*, for instance 0-255 sat/payload_byte, requir=
ing only one byte for the fee. The calculation of the actual fee can be per=
formed by both the network and the sender. The fee equals payload_size*feer=
ate + an-amount-calculated-by-preset-rules-such-that-it-raises-the-cost-of-=
the-transaction-to-only-marginally-less-than-what-it would-have-cost-to-sto=
re-the-same-amount-of-data-using-one-or-more-OP_RETURN-transactions.</span>=
</div><div dir=3D"auto"><span style=3D"border-color:rgb(0,0,0) rgb(0,0,0) r=
gb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><br></span></div><div style=3D=
"background-color:rgba(0,0,0,0)!important;border-color:rgb(255,255,255)!imp=
ortant;color:rgb(255,255,255)!important" dir=3D"auto"><font style=3D"border=
-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)">=
However explicitly specifying the fee amount is probably preferable for the=
 sake of transparency.</font></div><div style=3D"background-color:rgba(0,0,=
0,0);border-color:rgb(255,255,255)" dir=3D"auto"><br></div><div style=3D"ba=
ckground-color:rgba(0,0,0,0)!important;border-color:rgb(32,33,36)!important=
;color:rgb(255,255,255)!important" dir=3D"auto"><font style=3D"border-color=
:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)">I wond=
er if this proposal could technically work. I fully recognize though that e=
ven if it would, it has close to zero chances becoming reality as it breaks=
 the core design based on *U*TXOs (and likely also a lot of existing softwa=
re) =E2=80=94 thank you for pointing that out and for your helpful feedback=
.</font></div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb=
(255,255,255)" dir=3D"auto"><br></div><div style=3D"background-color:rgba(0=
,0,0,0)!important;border-color:rgb(255,255,255)!important;color:rgb(255,255=
,255)!important" dir=3D"auto"><font style=3D"border-color:rgb(0,0,0) rgb(0,=
0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)">Zac</font></div><div dir=
=3D"auto"><span style=3D"border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(=
204,204,204);color:rgb(0,0,0)"><br></span></div><div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 25 Feb 2022 at 13:48=
, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204)">Good morning Zac,<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; To me it seems that more space can be saved.<br>
&gt;<br>
&gt; The data-=E2=80=9Ctransaction=E2=80=9D need not specify any output. Th=
e network could subtract the fee amount of the transaction directly from th=
e specified UTXO.<br>
<br>
That is not how UTXO systems like Bitcoin work.<br>
Either you consume the entire UTXO (take away the &quot;U&quot; from the &q=
uot;UTXO&quot;) completely and in full, or you do not touch the UTXO (and c=
annot get fees from it).<br>
<br>
&gt; A fee also need not to be specified.<br>
<br>
Fees are never explicit in Bitcoin; it is always the difference between tot=
al input amount minus the total output amount.<br>
<br>
&gt; It can be calculated in advance both by the network and the transactio=
n sender based on the size of the data.<br>
<br>
It is already implicitly calculated by the difference between the total inp=
ut amount minus the total output amount.<br>
<br>
You seem to misunderstand as well.<br>
Fee rate is computed from the fee (computed from total input minus total ou=
tput) divided by the transaction weight.<br>
Nodes do not compute fees from feerate and weight.<br>
<br>
&gt; The calculation of the fee should be such that it only marginally chea=
per to use this new construct over using one or more transactions. For inst=
ance, sending 81 bytes should cost as much as two OP_RETURN transactions (m=
inus some marginal discount to incentivize the use of this more efficient w=
ay to store data).<br>
<br>
Do you want to change weight calculations?<br>
*reducing* weight calculations is a hardfork, increasing it is a softfork.<=
br>
<br>
&gt; If the balance of the selected UTXO is insufficient to pay for the dat=
a then the transaction will be invalid.<br>
&gt;<br>
&gt; I can=E2=80=99t judge whether this particular approach would require a=
 hardfork, sadly.<br>
<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--00000000000060df3505d8d808d5--