Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D7531C000A for ; 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 ; 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 ; 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 ; Fri, 16 Apr 2021 15:33:51 +0000 (UTC) Received: by mail-oo1-xc2e.google.com with SMTP id i20-20020a4a8d940000b02901bc71746525so6223722ook.2 for ; 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: In-Reply-To: From: Christopher Gilliard Date: Fri, 16 Apr 2021 15:33:40 +0000 Message-ID: To: Clark Moody Content-Type: multipart/alternative; boundary="000000000000edb86a05c018b475" X-Mailman-Approved-At: Fri, 16 Apr 2021 15:47:09 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
>>Maybe I missed something, but why does this change requir= e a hard fork?

I guess you are right = that it doesn'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's a spe= cific soft fork being proposed to merge this proposal with, I can update it= .

>>=C2=A0I'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.

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's much like submitting a transaction to the network today, if one of = the miners does not accept it, another likely will.

>>=C2=A0Some 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.

Good point, there are other ways to do= proof of burn.
=
>>=C2=A0Finally, 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.

= Yes, but tha= t 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 d= oes this change require a hard fork?

You don't seem to provide any data as pa= rt of your rationale, so I'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.

= I'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>
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.

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.


-Clark


On Fri, Apr 16, 2021 at 8:32 AM C= hristopher Gilliard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
I have created a BIP which can be found here:=C2=A0https://github.com/cgilliard/bips/blob/notarization/bi= p-XXXX.mediawiki

I'm sending this email to start= the discussion regarding this proposal. If there are any comments/suggesti= ons, please let me know.

Regards,
Chris<= /div>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000edb86a05c018b475--