MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
In-Reply-To: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
From: Clark Moody <clark@clarkmoody.com>
Date: Fri, 16 Apr 2021 08:59:01 -0500
Message-ID: <CAHGSxGuKcf4j7wzzq50pknJU1jW+FtSuPhyJNqniRmaTic6k+w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Christopher Gilliard <christopher.gilliard@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000063e86d05c01763b6"
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Precedence: list

--00000000000063e86d05c01763b6
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s=
ans-serif;font-size:small;color:#000000">Maybe I missed something, but why =
does this change require a hard fork?</div><div class=3D"gmail_default" sty=
le=3D"font-family:tahoma,sans-serif;font-size:small;color:#000000"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-=
size:small;color:#000000">You don&#39;t seem to provide any data as part of=
 your rationale, so I&#39;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.=
</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;f=
ont-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:tahoma,sans-serif;font-size:small;color:#000000">I&#39;m al=
so concerned about the coordination required to get into The One OP_RETURN =
Per Block, as this certainly requires some measure of centralization of tha=
t Merkle Tree construction.<br></div><div class=3D"gmail_default" style=3D"=
font-family:tahoma,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:s=
mall;color:#000000">Some of those OP_RETURN outputs have non-zero value. As=
 such, those outputs are provably unspendable, and they are essentially pay=
ing the rest of the coin holders via supply deflation.</div><div class=3D"g=
mail_default" style=3D"font-family:tahoma,sans-serif;font-size:small;color:=
#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma=
,sans-serif;font-size:small;color:#000000">Finally, Bitcoin nodes may safel=
y 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.<br></div><=
div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sign=
ature"><div><br></div><div><br></div><div>-Clark</div><div></div></div></di=
v><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</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">I have created a BIP which can be f=
ound here:=C2=A0<a href=3D"https://github.com/cgilliard/bips/blob/notarizat=
ion/bip-XXXX.mediawiki" target=3D"_blank">https://github.com/cgilliard/bips=
/blob/notarization/bip-XXXX.mediawiki</a><div><br></div><div>I&#39;m sendin=
g this email to start the discussion regarding this proposal. If there are =
any comments/suggestions, please let me know.</div><div><br></div><div>Rega=
rds,</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>

--00000000000063e86d05c01763b6--