path: root/af/22593bd81f86febde91950cabe0e00afd246c9

Return-Path: <zachgrw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2C71CC0011
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 01:12:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0FC7F41703
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 01:12:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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_FONT_LOW_CONTRAST=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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xtaE7I1pehey
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 01:12:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com
 [IPv6:2607:f8b0:4864:20::d36])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 5650A416ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Feb 2022 01:12:46 +0000 (UTC)
Received: by mail-io1-xd36.google.com with SMTP id q8so4888320iod.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Feb 2022 17:12:46 -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=uGA9XB4pJ5+xvYLg++STc79XZx2TuaaH8lYZMD6Ihfk=;
 b=VNJWQmWELVcd0n3Y24wSQClF1Y03Q7wsQ1HnhB6RqVf6obHVrnH6IV8H+TVj1eSsBQ
 ZNTmqYeKl4RZqCwFjP0Uku5xAjjMKf1k0791VmGXpwu3z5onzlOeZ4gocGjbP2Fl9mlf
 Rt9iYK1psrim/FkdvkBZnOPvO2Y/wdT2KjNZW6HfWi/fCnku/Eer5aLgnOYZr9XMGJaN
 lMQMYcjkoJmDdVeNUcqQv9SLtMaRNgGJ2OiEWa5/fzHpZXY/9gCXQzHCTN3f6DFr5g15
 QPRv9NNzODLL2f6/hSn8KaD2nBLKfWZgXjvYNWMzSrKyaIzFGDfZQR2om7yriRGnUKOQ
 YHTg==
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=uGA9XB4pJ5+xvYLg++STc79XZx2TuaaH8lYZMD6Ihfk=;
 b=1EhnHIF4bynX96nUM3WXrMvecWU0TJv89a5Qhj14/XwGQWIhGTBJshgV9uoUwip0+v
 KV0E3dfBOlV9a0tkjHB98YPDIX+w9hdtybvseOf9iNUfcGgyV3L9nakTB0r7y0THkFta
 OHV56X+oAJ5cdrc8UjNvNRYo67K8bBYuBaNsT6GymkuKcKuiCpocScZQY8Frzzl1aKfH
 /tfPXrPKE/8VZlVsoZFM5wyKzY/vnZJeOvoz5PhtqheVqDbsai1M1iNOQNCaP86he/d4
 ctCS8uqiwO2VIAG7yg9c5cT7i7jhdM4CxsKByr26pG+tfl3b9Aq/zxHfBb2h3Lf9CkFS
 RNGQ==
X-Gm-Message-State: AOAM5313kZle7lavkFVmt+DjTaeeZevGHDPDA4JUuyoFErjkEF9NcMeW
 454TSjhv52YyqoK3Aq1KbIqHtOO6ADzIAKkOEZE=
X-Google-Smtp-Source: ABdhPJztd4nzDjnLLtcspTQKAPMN69iG5+AhJ8ntMHkjfK801bJfYeyAhdf6HiFL4a83jxJTvFEUUC2dTx2PFEv1/zs=
X-Received: by 2002:a5d:9c07:0:b0:640:793d:636 with SMTP id
 7-20020a5d9c07000000b00640793d0636mr3868542ioe.102.1645751565439; Thu, 24 Feb
 2022 17:12:45 -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>
In-Reply-To: <vmZt7irtItdhrsha-cHM0-HgzhCQ6GlWdJXr6mKzEHXmoNz5ypuQLR9eKsltreHb0O2kMfcr_VRkZ1hmoJ9RAp5DaMZorhG1JsRSclhin6s=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Fri, 25 Feb 2022 02:12:34 +0100
Message-ID: <CAJ4-pECnAebQGN2=22ifGga9rtO2svdxY1bX96_VEW-wpjEpWw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000072589a05d8cd65f6"
X-Mailman-Approved-At: Fri, 25 Feb 2022 01:24:09 +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 01:12:47 -0000

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

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 footprint 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 see=
m useful.

Zac

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

> Good morning Zac,
>
> > Reducing the footprint of storing data on-chain might better be achieve=
d
> by *supporting* it.
> >
> > Currently storing data is wasteful because it is embedded inside an
> OP_RETURN within a transaction structure. As an alternative, by supportin=
g
> storing of raw data without creating a transaction, waste can be reduced.
>
> If the data is not embedded inside a transaction, how would I be able to
> pay a miner to include the data on the blockchain?
>
> I need a transaction in order to pay a miner anyway, so why not just embe=
d
> it into the same transaction I am using to pay the miner?
> (i.e. the current design)
>
>
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"auto">Hi=C2=A0<span style=3D"color:rgb(0,0,0)">ZmnSCPxj,</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,255)!important" dir=3D"auto"><font sty=
le=3D"color:rgb(0,0,0)">Any benefits of my proposal depend on my presumptio=
n that using a standard transaction for storing data must be inefficient. P=
resumably 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 st=
orage within some specialized, more space-efficient data structure at margi=
nally lower fee per payload-byte should enable reducing the footprint of st=
oring data on-chain.</font></div><div style=3D"background-color:rgba(0,0,0,=
0);border-color:rgb(255,255,255)" dir=3D"auto"><font style=3D"color:rgb(0,0=
,0)"><br></font></div><div style=3D"background-color:rgba(0,0,0,0)!importan=
t;border-color:rgb(32,33,36)!important;color:rgb(255,255,255)!important" di=
r=3D"auto"><font style=3D"color:rgb(0,0,0)">In case storing data through OP=
_RETURN embedded within a transaction is optimal in terms of on-chain footp=
rint then my proposal doesn=E2=80=99t seem useful.</font></div><div style=
=3D"background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"au=
to"><font style=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"backgro=
und-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><font s=
tyle=3D"color:rgb(0,0,0)">Zac</font></div><div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 25 Feb 2022 at 01:05, ZmnS=
CPxj &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 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef=
t:1ex;border-left-color:rgb(204,204,204)">Good morning Zac,<br>
<br>
&gt; Reducing the footprint of storing data on-chain might better be achiev=
ed by *supporting* it.<br>
&gt;<br>
&gt; Currently storing data is wasteful because it is embedded inside an OP=
_RETURN within a transaction structure. As an alternative, by supporting st=
oring of raw data without creating a transaction, waste can be reduced.<br>
<br>
If the data is not embedded inside a transaction, how would I be able to pa=
y a miner to include the data on the blockchain?<br>
<br>
I need a transaction in order to pay a miner anyway, so why not just embed =
it into the same transaction I am using to pay the miner?<br>
(i.e. the current design)<br>
<br>
<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--00000000000072589a05d8cd65f6--