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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Precedence: list

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