path: root/31/a98ae1fbd196cf5268bc3b542585c5d06696b2

Return-Path: <zachgrw@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 172A7C001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 13:54:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E4F66401D5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 13:54:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hNfJLBLALoDg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 13:54:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com
 [IPv6:2607:f8b0:4864:20::d2d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id A54374000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 13:54:09 +0000 (UTC)
Received: by mail-io1-xd2d.google.com with SMTP id d19so6531982ioc.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 05:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=TFokXaE9xmC+Lng3V2x8Gwvnu0prM5q5WRnCJDckPZQ=;
 b=e9DaKE40tKGb8YZ70Wmv3p1SrXRyQnwzSJq/2BMsY5BRgxLJjoaBekXoParMdUhqSH
 pI0SGeiWxVMWY2GZwD94Lt4As1aw56uyak5Ymh4GfxON5ZWJhT0dkqNxYRfH8qAzU4/h
 k+SWa3Yz7Kxw2NltVTnPFXdbfCVvDEgoXYbNAi92ZDp1irzOJq1s7YZ4eVFCqImS7qIA
 s7i13HW7c8QLq6+qPp2/27QfsD2fbEWNoMZtOnKmm1I06UX5ot97uCcFZSwG+UWg5Geu
 bz6Ri/DDSYHQwt4uuyv1XREWXluc3rmjSJvx2eP2MC213WQQ9UgxQUzQl284fjAK3xFW
 iu2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=TFokXaE9xmC+Lng3V2x8Gwvnu0prM5q5WRnCJDckPZQ=;
 b=KyK33ZmEz1oAtzjjLAEvFYjEAbGNgfcc97CDcBAYoEGNqEcaCIjWhBF4mBY3nFV2ov
 1yGQ5w5gga8w87ciFkJAgI5UqpM63iI8+idrhMLao9BJEr/zNYXby0+IbGf/Iqou0Mrt
 wTosh/9NF5OFu6Vvg5h56ClusxJbtkXOsnPXDgK8SNquLHQ4zVLY+aDYJJjH0QB+02xK
 J9QhKTLmXLKpdNjYfr7d+FP6tIOXd9SOPpB1XAw7REkGejKBxlLSk+Bsx3RWY9HbwQP6
 5UAEWPX1qP0WYB1JCAiqSH1ENL5Cr43XllGQ+dsRk5IfsTWVwRDMdTuKyxleEHpn+SAt
 UtfA==
X-Gm-Message-State: AOAM531wu7FMWt4LTFz4XRmVwN9U3GFER5+oklspMPaKEjtQdEG+v1AC
 lOobPUYNoaZMjX4zXIKhVVKXUr0DaB8y83hZAi/I8R8g
X-Google-Smtp-Source: ABdhPJx0Z17KRAUX49nVMZRpXeQVu6PiPh02pX/RSgUX37RfbLDQkaZugsilBwY9dg34WDNRHJI4i9ZVkt+TmvTm1TM=
X-Received: by 2002:a05:6638:d52:b0:314:d4d9:f8e4 with SMTP id
 d18-20020a0566380d5200b00314d4d9f8e4mr5889817jak.139.1645797248654; Fri, 25
 Feb 2022 05:54:08 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 25 Feb 2022 14:20:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Feb 2022 13:54:11 -0000

--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--