path: root/da/e1db06fb03225d01d8b2ab54e625aff75a0d96

Return-Path: <zachgrw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7FD13C001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 07:15:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 687AF83774
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 07:15:19 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id uqQySzvsHty4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 07:15:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [IPv6:2607:f8b0:4864:20::d2f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 22A7E83490
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 07:15:18 +0000 (UTC)
Received: by mail-io1-xd2f.google.com with SMTP id s1so5505453iob.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 23:15:18 -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=SJGwQaJ8X0hx1EQgj2MSvGbAFU0n3iqHMoqoEyd8COk=;
 b=AMF8Y3uL6CFMSvjFBPmUDZwj4D4RvhJbfly9dMWZ0rUeOSZP9SnxIGOHya9/sXbOS9
 DwtGWeEFtOxV05frMCEiiEg1HTRmq935j0cfIPevYr90EF+lKApmrtqjH98hKoUcO38k
 +tjjMv9YRvHHLEI91o96o/GT4OT8xIFAUi11Z+Zuqgj26GIPzZwzH3O4S+YDq7+TxsnE
 fEZ2EOYyHbgdVEVQ+1tJUqkwbVgJUh5wQT+mMMp2JEnlrwVTfszg/dYIZK6Km29Hj7Cb
 3TNnZmCq53S7HMVVX/jnfg9+kGDaJNRTiCanucBDM2nJiccA3Z7IjArwZDsZFDaIBsFj
 4qoA==
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=SJGwQaJ8X0hx1EQgj2MSvGbAFU0n3iqHMoqoEyd8COk=;
 b=n+60RtPoi6s/fa0+BISweGfpmI0i9CAy5eyHPHt1RC2TN3rn2oa/g0MU6ZHiyl2dTA
 Ir2IngZ/w61GF7jlWP8o0DFtn9G5S3hLhWCz3hHnsYIz3dJkummLCMxM+2b0gAl/o0h5
 rERXd/3Z2xd9/cK9JWrhvvu1IiYM5/k6ZHeTf2otzY5iUrcONhb6XaCFH2V1cs+nKiCt
 WKqWJYXbjvR6iYbjLNTVoWkSPCHLqV3NrSqIzeXjGcZu+gk216rfzIMnGZC7wqT9/EcW
 MJBO/aygtCxu1V5rYrWTIcGJsawD5MxocaZkqFuag+pKDLGpoDOMWpgqbPxk4+EEMNps
 hQ9A==
X-Gm-Message-State: AOAM5323Z/vlhnBvYFLYyMJhMC6rrLxgAWKcoEMdduE2FIKMOn5u18tG
 g6a+aSMydHjTOUYGQJ1KEhfdSnPJPOuUaGvqRG4=
X-Google-Smtp-Source: ABdhPJx+F55zs51s+SeA2vKe0zUYCNMZ5a70gKhU8m5fJhDQ5Wo+1av3D0R2ddcNItn9XKuZTmQncJgAaeRfeo72kzk=
X-Received: by 2002:a5d:8b06:0:b0:642:1ca5:9551 with SMTP id
 k6-20020a5d8b06000000b006421ca59551mr1863335ion.141.1645773317296; Thu, 24
 Feb 2022 23:15:17 -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>
In-Reply-To: <XrV3nIrTZfdzTb7tsbwX5xP4COd6pXCA076lWzbXvbhnn7bx6kThL5JzeCxwoimCXKmpux5Gbjycj7t6X8ncYBWx5-HMi2voDuKZm27_h00=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Fri, 25 Feb 2022 08:15:06 +0100
Message-ID: <CAJ4-pEDAKPFQF-tuzYw+Hc0moViZ4kyoVz91mESkqb-GQZ35aQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f5564d05d8d275d0"
X-Mailman-Approved-At: Fri, 25 Feb 2022 08:47:56 +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 07:15:19 -0000

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

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 net=
work could
subtract the fee amount of the transaction directly from the specified
UTXO. A fee also need not to be specified. It can be calculated in advance
both by the network and the transaction sender based on the size of the
data.

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

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 hard=
fork,
sadly.

Zac


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

> 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 footprin=
t
> 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=E2=80=99t s=
eem 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, t=
he
> 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
>

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

<div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-colo=
r:rgb(49,49,49);color:rgb(49,49,49)">Hi=C2=A0<span style=3D"font-size:1rem;=
border-color:rgb(0,0,0);color:rgb(0,0,0)">ZmnSCPxj,</span></div><div dir=3D=
"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);=
color:rgb(49,49,49)"><span style=3D"border-color:rgb(0,0,0);color:rgb(0,0,0=
)"><br></span></div><div dir=3D"auto" style=3D"font-size:16px;word-spacing:=
1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><span style=3D"font-siz=
e:1rem;border-color:rgb(0,0,0);color:rgb(0,0,0)">To me it seems that more s=
pace can be saved.</span></div><div dir=3D"auto" style=3D"font-size:16px;wo=
rd-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div><d=
iv dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(2=
55,255,255)"><font style=3D"font-size:1rem;border-color:rgb(0,0,0);color:rg=
b(0,0,0)">The data-=E2=80=9Ctransaction=E2=80=9D need not specify any outpu=
t. The network could subtract the fee amount of the transaction directly fr=
om the specified UTXO. A fee also need not to be specified. It can be calcu=
lated in advance both by the network and the transaction sender based on th=
e size of the data.</font></div><div dir=3D"auto" style=3D"font-size:16px;w=
ord-spacing:1px;border-color:rgb(255,255,255);color:rgb(49,49,49)"><font st=
yle=3D"border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></font></div><div dir=
=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(255,255=
,255);color:rgb(49,49,49)"><font style=3D"font-size:1rem;border-color:rgb(0=
,0,0);color:rgb(0,0,0)">The calculation of the fee should be such that it o=
nly marginally cheaper to use this new construct over using one or more tra=
nsactions. For instance, sending 81 bytes should cost as much as two OP_RET=
URN transactions (minus some marginal discount to incentivize the use of th=
is more efficient way to store data).</font></div><div dir=3D"auto" style=
=3D"font-size:16px;word-spacing:1px;border-color:rgb(255,255,255);color:rgb=
(49,49,49)"><font style=3D"border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></=
font></div><div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;borde=
r-color:rgb(255,255,255);color:rgb(49,49,49)"><font style=3D"font-size:1rem=
;border-color:rgb(0,0,0);color:rgb(0,0,0)">If the balance of the selected U=
TXO is insufficient to pay for the data then the transaction will be invali=
d.</font></div><div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;b=
order-color:rgb(255,255,255);color:rgb(49,49,49)"><font style=3D"border-col=
or:rgb(0,0,0);color:rgb(0,0,0)"><br></font></div><div dir=3D"auto" style=3D=
"font-size:16px;word-spacing:1px;border-color:rgb(255,255,255);color:rgb(49=
,49,49)"><font style=3D"font-size:1rem;border-color:rgb(0,0,0);color:rgb(0,=
0,0)">I can=E2=80=99t judge whether this particular approach would require =
a hardfork, sadly.</font></div><div dir=3D"auto" style=3D"font-size:16px;wo=
rd-spacing:1px;border-color:rgb(255,255,255);color:rgb(49,49,49)"><font sty=
le=3D"font-size:1rem;border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></font><=
/div><div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-colo=
r:rgb(255,255,255);color:rgb(49,49,49)"><font style=3D"font-size:1rem;borde=
r-color:rgb(0,0,0);color:rgb(0,0,0)">Zac</font></div><div dir=3D"auto" styl=
e=3D"font-size:16px;word-spacing:1px;border-color:rgb(255,255,255);color:rg=
b(49,49,49)"><font style=3D"font-size:1rem;border-color:rgb(0,0,0);color:rg=
b(0,0,0)"><br></font></div></div><div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Fri, 25 Feb 2022 at 04:19, ZmnSCPxj &lt;=
<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;bor=
der-left-color:rgb(204,204,204)">Good morning Zac,<br>
<br>
&gt; Hi=C2=A0ZmnSCPxj,<br>
&gt;<br>
&gt; Any benefits of my proposal depend on my presumption that using a stan=
dard transaction for storing data must be inefficient. Presumably a transac=
tion takes up significantly more on-chain space than the data it carries wi=
thin its OP_RETURN. Therefore, not requiring a standard transaction for dat=
a storage should be more efficient. Facilitating data storage within some s=
pecialized, more space-efficient data structure at marginally lower fee per=
 payload-byte should enable reducing the footprint of storing data on-chain=
.<br>
&gt;<br>
&gt; In case storing data through OP_RETURN embedded within a transaction i=
s optimal in terms of on-chain footprint then my proposal doesn=E2=80=99t s=
eem useful.<br>
<br>
You need to have some assurance that, if you pay a fee, this data gets on t=
he blockchain.<br>
And you also need to pay a fee for the blockchain space.<br>
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.<br>
But that is already an existing transaction structure, the transaction inpu=
t.<br>
If you are not going to pay an entire UTXO for it, you need a transaction o=
utput as well to store the change.<br>
<br>
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.<br>
We already have a structure for that, the transaction.<br>
<br>
So an `OP_RETURN` transaction output is added and you put published data th=
ere, and existing constructions make everything Just Work (TM).<br>
<br>
Now I admit we can shave off some bytes.<br>
Pure published data does not need an amount, and using a transaction output=
 means there is always an amount field.<br>
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).<br>
<br>
But that is not really a lot of bytes, and adding a separate field to the t=
ransaction would require a hardfork.<br>
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.<br>
If we *could*, then a separate field for data publication would be softfork=
able, but the technique does not apply here.<br>
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`.<br>
If you have a separate signature that is in the `dtxid`, then you spend mor=
e actual bytes to save a few bytes.<br>
<br>
Saving a few bytes for an application that is arguably not the &quot;job&qu=
ot; of Bitcoin (Bitcoin is supposed to be for value transfer, not data arch=
iving) is not enough to justify a **hard**fork.<br>
And any softfork seems likely to spend more bytes than what it could save.<=
br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--000000000000f5564d05d8d275d0--