From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9C360C000C for ; Fri, 16 Apr 2021 13:59:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 78E5B60DEB for ; Fri, 16 Apr 2021 13:59:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=clarkmoody-com.20150623.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQhBFx86Thw8 for ; Fri, 16 Apr 2021 13:59:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4BD6F60715 for ; Fri, 16 Apr 2021 13:59:29 +0000 (UTC) Received: by mail-ot1-x32a.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so25816884otn.1 for ; Fri, 16 Apr 2021 06:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clarkmoody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HjFEvNC0d6EnJAx2ixIBQyAe/GDN9vVh78tcizZo3xU=; b=Q5+YoAQOMm7Cn5YUxxW+IxGPW0pMJLIIPM6pFZJHpCQzXLDTdl1hc6+AFCZI35wLcj 6Etzt+xYVnLQ1QpDE4NHrSEt5JqSurX9oIbXY2XTYG9NpSjczlVyHQHzT/jhO2JVEw8e LuHaoIGyGzXqxyN1phi5CGWsR1558LgDxNBjU0a6XpvJTekoaB8k2FFfZhD3AWDCz6aZ UobDjzkrhZKrtbjbhY8u2kabXwnYxTcrGb9GViISgP2stO+k97rDLSbEUj5BABpNzTit U3eivvbtxVVj/IhfkNZoY/1wPbei+OGQF1MSR32THVzr4sq/ZtzjW1jHfoSSkq61sG5C DfRw== 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; bh=HjFEvNC0d6EnJAx2ixIBQyAe/GDN9vVh78tcizZo3xU=; b=ltUzbn8jUaRa4p4ls5pleZOYTbqhCOfybFDxehx5s/bdsragEfPVQolNAPFB700ixO 24/PISn05XiJpVwuX3/DwJ6o25j+j/RrEJwdW1KNpTKR44VqXGcJbQcY7ph35T1VOz+b aYrihfhE7ewa+1+pkB9aCVwI1m/kYy0hbE+60FqnwULkjFOxkKhf74nDGdBfudCy9Hqg ccyEZAyZysuzsBzFp68OkBH5KeiyX+u9QMx2b2px0N2VyGbs7lfqjtTpaI8ohWa7OgFO YKNbhj481PBFJb7u48s1AnWeVHV9ib0xz0SL2H7Z/NhJW0/ciZabTWZSHSuIZHajMJto gqQA== X-Gm-Message-State: AOAM5309GRTQWGMNvLkw3sa+OeR4d+RiMHebZzx2X1mJ+U+Q6O3k60AF PQrFQfvPUQXUJfmZhOClWJ25vUapN/4kPVso3MXpFUnk0GwAiw== X-Google-Smtp-Source: ABdhPJwNDrwh/6PUf7/+cT1bQBj1Yz/kYJvQWBb7mMfkI1hmgOpK4wB5UVpKBAv54SOEDnSef/ioXEKC0pw3VTUz5nE= X-Received: by 2002:a9d:38c:: with SMTP id f12mr3847010otf.10.1618581567824; Fri, 16 Apr 2021 06:59:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clark Moody Date: Fri, 16 Apr 2021 08:59:01 -0500 Message-ID: To: Bitcoin Protocol Discussion , Christopher Gilliard Content-Type: multipart/alternative; boundary="00000000000063e86d05c01763b6" X-Mailman-Approved-At: Fri, 16 Apr 2021 14:00:38 +0000 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 13:59:33 -0000 --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
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 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.

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.

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.
<= div>


-Clark


On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev = <bitcoin-dev@li= sts.linuxfoundation.org> wrote:
I have created a BIP which can be f= ound here:=C2=A0https://github.com/cgilliard/bips= /blob/notarization/bip-XXXX.mediawiki

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

Rega= rds,
Chris
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000063e86d05c01763b6--