path: root/19/aab0b45dfb2302fd6dfa4511b0e5101d02aedd

Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D7531C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 15:33:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B158E84AAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 15:33:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, 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 hLhfUj1XJS56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 15:33:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com
 [IPv6:2607:f8b0:4864:20::c2e])
 by smtp1.osuosl.org (Postfix) with ESMTPS id C4D8084A9D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 15:33:51 +0000 (UTC)
Received: by mail-oo1-xc2e.google.com with SMTP id
 i20-20020a4a8d940000b02901bc71746525so6223722ook.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 08:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=1lzcf+fH9sgqksbSVQ9SQDRSKjoMo9Fku1JL++0O8CU=;
 b=NVArNTBs5PRbg1prUzigN8r9GKpCGUJvkl1z034TE7AQq/mNrE4+9hNEgRIfcKR0G7
 cDzThm+a1Kqff41U4jio+h6Bv+6ZQTTl7uCYkqFO972M5JYwHNbIMajk+YqRLNKd93ki
 WzjtTSK7v/PtrCFcRBiLaTtIoKBYerUu9mSe0fTw+IZOK+b6vzUMpQIxsbKk+13LjalY
 fEr30FO+aseiUQ++G2O4XbhkPIHz0HDH+Anan3kX+8jV3Dghq1e2ogpxi1JHsAOHdKKW
 Boz8Gjjh/wuMsN3PJzOfGU1BG4kvbNs1re1ncZnBdY/G/97XVreLUJkEQlUnMV8gAPMf
 w0GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=1lzcf+fH9sgqksbSVQ9SQDRSKjoMo9Fku1JL++0O8CU=;
 b=IZlLwGFtUZamCEdg1OXfyrLf41u03oFP/v96pcM7tVWRloR0l3BHsvLM/2Xi+OSc7B
 7CzTIK5Up9KZjgc517GWZI1Hd0K4PnXoVG/s88ngLSyNGfCZJz7jQZz369QTuLTak8OP
 5uE8/tGrgnZ8jVv6t3ERg8KLRhwYiWKzJax/7UCFfxM0saXvjvNBb+oTl7bxFDDO2EMx
 zLnWNGxBsHYBMaKSr6Cl8EL2zEi1P+uGjvzIQP1KngM5i09HGw4Srzg61aIjtZeZsQJr
 Z/0Dey8vWBBDzep00rkBLIunpX4U4YKRH3fbY2uGspAhn7r8Kq1ovYZ7FiuF2RaZoofl
 jXWA==
X-Gm-Message-State: AOAM5311aCBYTX+uUT/8skkOOgeQVihM3J7p7BaA6DZLvIKNzXrZM2JI
 uVIZcCBCh65Fezk0bml3yMlCCkzwVgyuixoND1w=
X-Google-Smtp-Source: ABdhPJxXdSNeK9Xc9+qwADhuHn33yqlERdJ9bVhjssUOi15cssINZpnOs+ST18NASKxbPTBJpYW6UOJXDQwmsDqsMvk=
X-Received: by 2002:a4a:d553:: with SMTP id q19mr3806243oos.28.1618587230778; 
 Fri, 16 Apr 2021 08:33:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
 <CAHGSxGuKcf4j7wzzq50pknJU1jW+FtSuPhyJNqniRmaTic6k+w@mail.gmail.com>
In-Reply-To: <CAHGSxGuKcf4j7wzzq50pknJU1jW+FtSuPhyJNqniRmaTic6k+w@mail.gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Fri, 16 Apr 2021 15:33:40 +0000
Message-ID: <CAK=nyAwLVZEj_=hg2owFPSTgxcBakq7viWshjj_Zdj8ph2w1VA@mail.gmail.com>
To: Clark Moody <clark@clarkmoody.com>
Content-Type: multipart/alternative; boundary="000000000000edb86a05c018b475"
X-Mailman-Approved-At: Fri, 16 Apr 2021 15:47:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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, 16 Apr 2021 15:33:56 -0000

--000000000000edb86a05c018b475
Content-Type: text/plain; charset="UTF-8"

>>Maybe I missed something, but why does this change require a hard fork?

I guess you are right that it doesn't technically require a hard fork, but
I see this proposal as more likely being merged with other hard fork or
soft fork features. It depends on which upgrades are happening at the time.
If there's a specific soft fork being proposed to merge this proposal with,
I can update it.

>> I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.

This will be discussed further in a future BIP, but the basic idea is that
each miner can run an additional piece of software that builds the tree
structure. It's much like submitting a transaction to the network today, if
one of the miners does not accept it, another likely will.

>> Some of those OP_RETURN outputs have non-zero value. As such, those
outputs are provably unspendable, and they are essentially paying the rest
of the coin holders via supply deflation.

Good point, there are other ways to do proof of burn.

>> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.

Yes, but that doesn't affect IBD.

On Fri, Apr 16, 2021 at 1:59 PM Clark Moody <clark@clarkmoody.com> wrote:

> Maybe I missed something, but why does this change require a hard fork?
>
> You don't seem to provide any data as part of your rationale, so I'll
> provide some context. As it stands, the chain size sits around 386 GB, with
> OP_RETURN data accounting for 2.5 GB of that.
>
> I'm also concerned about the coordination required to get into The One
> OP_RETURN Per Block, as this certainly requires some measure of
> centralization of that Merkle Tree construction.
>
> Some of those OP_RETURN outputs have non-zero value. As such, those
> outputs are provably unspendable, and they are essentially paying the rest
> of the coin holders via supply deflation.
>
> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
> since they are unspendable. Thus, nodes can clear a few GB of disk space
> whenever they need it, but that data is less than 1% of the total chain
> size at the time of writing.
>
>
> -Clark
>
>
> On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr"><div>&gt;&gt;<span style=3D"color:rgb(0,0,0);font-family:t=
ahoma,sans-serif">Maybe I missed something, but why does this change requir=
e a hard fork?</span></div><div class=3D"gmail_default" style=3D"font-famil=
y:tahoma,sans-serif;color:rgb(0,0,0)"><br></div><div>I guess you are right =
that it doesn&#39;t technically require a hard fork, but I see this proposa=
l as more likely being merged with other hard fork or soft fork features. I=
t depends on which upgrades are happening at the time. If there&#39;s a spe=
cific soft fork being proposed to merge this proposal with, I can update it=
.<br></div><div><br></div><span class=3D"gmail-im" style=3D"color:rgb(80,0,=
80)">&gt;&gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:tahoma,sans-=
serif">I&#39;m also concerned about the coordination required to get into T=
he One OP_RETURN Per Block, as this certainly requires some measure of cent=
ralization of that Merkle Tree construction.</span><div><br></div></span><d=
iv><span style=3D"color:rgb(0,0,0);font-family:tahoma,sans-serif">This will=
 be discussed further in a future BIP, but the basic idea is that each mine=
r can run an additional piece of software that builds the tree structure. I=
t&#39;s much like submitting a transaction to the network today, if one of =
the miners does not accept it, another likely will.</span></div><span class=
=3D"gmail-im" style=3D"color:rgb(80,0,80)"><div><span style=3D"color:rgb(0,=
0,0);font-family:tahoma,sans-serif"><br></span></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:tahoma,sans-serif">&gt;&gt;=C2=A0</span><span st=
yle=3D"color:rgb(0,0,0);font-family:tahoma,sans-serif">Some of those OP_RET=
URN outputs have non-zero value. As such, those outputs are provably unspen=
dable, and they are essentially paying the rest of the coin holders via sup=
ply deflation.</span></div><div><span style=3D"color:rgb(0,0,0);font-family=
:tahoma,sans-serif"><br></span></div></span><div><span style=3D"color:rgb(0=
,0,0);font-family:tahoma,sans-serif">Good point, there are other ways to do=
 proof of burn.</span></div><span class=3D"gmail-im" style=3D"color:rgb(80,=
0,80)"><div><span style=3D"color:rgb(0,0,0);font-family:tahoma,sans-serif">=
<br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:tahoma,sa=
ns-serif">&gt;&gt;=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:=
tahoma,sans-serif">Finally, Bitcoin nodes may safely discard OP_RETURN outp=
uts at any time, since they are unspendable. Thus, nodes can clear a few GB=
 of disk space whenever they need it, but that data is less than 1% of the =
total chain size at the time of writing.</span></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:tahoma,sans-serif"><br></span></div></span><div>=
<span style=3D"color:rgb(0,0,0);font-family:tahoma,sans-serif">Yes, but tha=
t doesn&#39;t affect IBD.</span></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021 at 1:59 PM Clark=
 Moody &lt;<a href=3D"mailto:clark@clarkmoody.com">clark@clarkmoody.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-=
serif;font-size:small;color:rgb(0,0,0)">Maybe I missed something, but why d=
oes this change require a hard fork?</div><div class=3D"gmail_default" styl=
e=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><br></=
div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">You don&#39;t seem to provide any data as pa=
rt of your rationale, so I&#39;ll provide some context. As it stands, the c=
hain size sits around 386 GB, with OP_RETURN data accounting for 2.5 GB of =
that.</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default=
" style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">=
I&#39;m also concerned about the coordination required to get into The One =
OP_RETURN Per Block, as this certainly requires some measure of centralizat=
ion of that Merkle Tree construction.<br></div><div class=3D"gmail_default"=
 style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><=
br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri=
f;font-size:small;color:rgb(0,0,0)">Some of those OP_RETURN outputs have no=
n-zero value. As such, those outputs are provably unspendable, and they are=
 essentially paying the rest of the coin holders via supply deflation.</div=
><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">Finally, B=
itcoin nodes may safely discard OP_RETURN outputs at any time, since they a=
re unspendable. Thus, nodes can clear a few GB of disk space whenever they =
need it, but that data is less than 1% of the total chain size at the time =
of writing.<br></div><div><div dir=3D"ltr"><div><br></div><div><br></div><d=
iv>-Clark</div><div></div></div></div><br></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021 at 8:32 AM C=
hristopher Gilliard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">I have created a BIP which can be found here:=C2=A0<a hr=
ef=3D"https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawik=
i" target=3D"_blank">https://github.com/cgilliard/bips/blob/notarization/bi=
p-XXXX.mediawiki</a><div><br></div><div>I&#39;m sending this email to start=
 the discussion regarding this proposal. If there are any comments/suggesti=
ons, please let me know.</div><div><br></div><div>Regards,</div><div>Chris<=
/div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000edb86a05c018b475--