summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRuben Somsen <rsomsen@gmail.com>2021-04-16 22:30:06 +0200
committerbitcoindev <bitcoindev@gnusha.org>2021-04-16 20:30:26 +0000
commit25f3a7fa880c457a92179e6c68eddbbf46390ae8 (patch)
treec08498ce3138d9c95c75bbd23428ae26edb74d20
parentb6e8b27c2c6b39c0fb7c5ba29fcd00be422b9a94 (diff)
downloadpi-bitcoindev-25f3a7fa880c457a92179e6c68eddbbf46390ae8.tar.gz
pi-bitcoindev-25f3a7fa880c457a92179e6c68eddbbf46390ae8.zip
Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
-rw-r--r--e6/a14c84600f36be7256912989585ec3a402acf5317
1 files changed, 317 insertions, 0 deletions
diff --git a/e6/a14c84600f36be7256912989585ec3a402acf5 b/e6/a14c84600f36be7256912989585ec3a402acf5
new file mode 100644
index 000000000..6354ea1e9
--- /dev/null
+++ b/e6/a14c84600f36be7256912989585ec3a402acf5
@@ -0,0 +1,317 @@
+Return-Path: <rsomsen@gmail.com>
+Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id 9F379C000A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 16 Apr 2021 20:30:26 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp4.osuosl.org (Postfix) with ESMTP id 7890B418CC
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 16 Apr 2021 20:30:26 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: -2.099
+X-Spam-Level:
+X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
+ tests=[BAYES_00=-1.9, 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_PASS=-0.001]
+ autolearn=ham autolearn_force=no
+Authentication-Results: smtp4.osuosl.org (amavisd-new);
+ dkim=pass (2048-bit key) header.d=gmail.com
+Received: from smtp4.osuosl.org ([127.0.0.1])
+ by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id 4eKLCfQBN7rp
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 16 Apr 2021 20:30:22 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.8.0
+Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com
+ [IPv6:2a00:1450:4864:20::62a])
+ by smtp4.osuosl.org (Postfix) with ESMTPS id 680EA4189E
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 16 Apr 2021 20:30:22 +0000 (UTC)
+Received: by mail-ej1-x62a.google.com with SMTP id l4so43871779ejc.10
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 16 Apr 2021 13:30:22 -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;
+ bh=7+TvqrdW/hBhKkebZEB6kSbnLK8BY4ujIPci/mXoYK0=;
+ b=KvYSLHIWllVqJ0h10ex1vdOfWMUTrpidvkDgq6zCM/ACFz+2F0ckLNRRsPDDH+Qb4m
+ jMismpLHsirmFgrW94IDGBgf4NtYdEyP707aZdGJKyl/U1L5UB9RNUVcIUUV8vneqQAl
+ zweLQOvn5KwaEb+Cf5ayBQXUvPSA0zG5qMU/W4S/DqfQE6j2cO0U4gsEBnRxRsOMBtdG
+ Wr5qBDo9yh7lQ2Y/uI5axL+ROJrWMM6r3Dor9uv0zFqPxSqqqpaovF85/wAYUsO+PtJD
+ 2z/A4KiZU7pNm+Dn5cuuCVQFetG6/OJ6KhJy4+a2Akpwi+c5osmBCoi7OL3KS0v5mDhS
+ n7Ug==
+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=7+TvqrdW/hBhKkebZEB6kSbnLK8BY4ujIPci/mXoYK0=;
+ b=VCcj1US/0bp4kD1QeeX9Gf2HXEkdG9WS+2tKn7Lx0pO/uWNy4fAiyPIqGDlVxjn8NN
+ iR6LhuQPjJZvo1H1hJx+xho7Uv4Ldb3PX2o+m6vnp296BvDMdIRJAV2Tj+eUjr7zkKDN
+ xl1OZrY586C4FjOOQCvgvkPq5NCPV9P+QgzdHK2Zoze+nDlNY5/RzGzjINYyM9UjYBwv
+ Xpx4X668Nti9siFuQBSyJozSbNlasmZBuMGfUxFYw8QiiBUmlXq/zQf6pjDGLGJlC2yG
+ xI3jcLfR+7OCWZrU6LjJ3NaSCYuvXBOiMZ/LRWUFLhjKlzBcfhxj/WSH7G9ujooyViyX
+ fuBQ==
+X-Gm-Message-State: AOAM531jc1HaL78QAom97RzRAhhm+DXlAOVYsBnOpSxq26/XYlotpBov
+ ROqhTJqIumAdYaUBhfHGG1J8dnT41+i4jth/3KWEmoPgdCM=
+X-Google-Smtp-Source: ABdhPJzlufR5cVQOvhpST1i7qJ7J/IMnyx2V2lDKRfTHv/c9krtxjU0034rWAfMRTq3B9c3cH16ERJeNEKmOSHywDXg=
+X-Received: by 2002:a17:906:4347:: with SMTP id
+ z7mr9901418ejm.246.1618605020443;
+ Fri, 16 Apr 2021 13:30:20 -0700 (PDT)
+MIME-Version: 1.0
+References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
+ <CABE6yHscUPAcyK58DvqhOnxSOoPMBAy9aMUmReJYSkBit-Mekg@mail.gmail.com>
+In-Reply-To: <CABE6yHscUPAcyK58DvqhOnxSOoPMBAy9aMUmReJYSkBit-Mekg@mail.gmail.com>
+From: Ruben Somsen <rsomsen@gmail.com>
+Date: Fri, 16 Apr 2021 22:30:06 +0200
+Message-ID: <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com>
+To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
+ christopher.gilliard@gmail.com
+Content-Type: multipart/alternative; boundary="00000000000046772005c01cd908"
+X-Mailman-Approved-At: Fri, 16 Apr 2021 20:31:09 +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 <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 20:30:26 -0000
+
+--00000000000046772005c01cd908
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Hi Chris,
+
+I agree with all the points that were made by others. You should also be
+aware that layer two ideas like yours have already been explored, both by
+myself and others. Allowing one hash per block allows for what I call
+"fee-bidding Blind Merged-Mining" (BMM), which as far as I know was first
+proposed by Paul Storc for Drivechains.[0]
+
+If only one hash is allowed per block, then those who wish to utilize the
+hash will have to out-bid each other ("fee-bidding"). This hash can then be
+used to create another chain ("merged-mining"), while the Bitcoin miners do
+not have to be aware of this other chain ("blind"). There are also non
+fee-bidding variants that function e.g. by burning or locking up bitcoins
+in order to create consensus.
+
+As it turns out, fee-bidding BMM can be achieved using only a covenant
+structure for transactions.[1] You'd have to create a sequence of
+transactions (one per block), to which a hash can be attached. These can
+simply be pre-signed transactions (requires forgetting a key, but the worst
+that can happen is that the chain halts), or an actual covenant using
+either sighash_anyprevout or op_ctv (we don't have these yet) =E2=80=93 no
+specialized soft fork (or hard fork) is required.
+
+You might think any decentralized alternative chain requires an altcoin,
+but this can also be avoided with a perpetual one-way peg.[2] For more
+details, I recommend watching this video of the full concept, which I call
+"spacechains": https://youtu.be/N2ow4Q34Jeg
+
+-- Ruben Somsen
+
+
+
+[0] Blind Merged-Mining for Drivechains:
+https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki
+
+[1] Fee-bidding Blind Merged-Mining with covenants:
+https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
+
+[2] Perpetual one-way peg:
+https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-=
+the-perpetual-one-way-peg-96cb2f8ac302
+
+On Fri, Apr 16, 2021 at 9:33 PM Kostas Karasavvas via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> Hi Christopher,
+>
+> Some feedback:
+>
+> "OP_RETURN is limited to 40 bytes of data."
+> It is 80 bytes.
+>
+> "A future BIP proposing such a layer two protocol will be forthcoming."
+> So what is this BIP about? Just saying that it would be a nice idea? This
+> BIP should be the one that would go through this L2 suggestion. If one ro=
+ot
+> OP_RETURN substitutes all the rest it should say how that would be done..=
+.
+> where would the merkle proofs be stored, what are the trust
+> assumptions that we need to make, etc.
+>
+> "Objections to this proposal" section
+> I agree with others re hard-fork, which would be a good thing of course.
+> My main objection with this proposal is that I don't see a proposal. It
+> seems like wishful thinking... if only we could substitute all the
+> OP_RETURNs with one :-)
+>
+> We have to make sure that a proposal like this (L2, etc.) would make sure
+> that there are incentives that justify the added complexity for the users=
+.
+> Multisig is not the only way data could be stored the wrong way; P2PK,
+> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not go=
+od
+> enough people would start using these UTXO-bloat-heavy alternatives.
+>
+> There are a multitude of L2's (kind-of) that do this 'aggregation' of dat=
+a
+> hashes using merkle trees. Factom is adding a single merkle root per
+> bitcoin block for the millions upon millions of records (of thousand of
+> users) that they keep in their network. Opentimestamps, tierion,
+> blockstacks and others do a similar thing. I have investigated several of
+> those in the past, for one of my projects, but I ended up using plain old
+> OP_RETURN because the overhead of their (L2-like) solution and trust
+> assumptions where not to my liking; at least for my use case. They were
+> pretty solid/useful for other use cases.
+>
+> Unless the proposed L2 is flexible/generic enough it would really prohibi=
+t
+> this L2 innovation that OP_RETURN allowed (see above).
+>
+>
+>
+> On Fri, Apr 16, 2021 at 4:32 PM 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
+>>
+>
+>
+> --
+> Konstantinos A. Karasavvas
+> Software Architect, Blockchain Engineer, Researcher, Educator
+> https://twitter.com/kkarasavvas
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--00000000000046772005c01cd908
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Hi Chris,<div><br></div><div>I agree with all the points t=
+hat were made by others. You should also be aware that layer two ideas like=
+ yours have already been explored, both by myself and others. Allowing one =
+hash per block allows for what I call &quot;fee-bidding Blind Merged-Mining=
+&quot; (BMM), which as far as I know was first proposed by Paul Storc for D=
+rivechains.[0]</div><div><br></div><div>If only one hash is allowed per blo=
+ck, then those who wish to utilize the hash will have to out-bid each other=
+ (&quot;fee-bidding&quot;). This hash can then be used to create another ch=
+ain (&quot;merged-mining&quot;), while the Bitcoin miners do not have to be=
+ aware of this other chain (&quot;blind&quot;). There are also non fee-bidd=
+ing variants that function e.g. by burning or locking up bitcoins in order =
+to create consensus.</div><div><br></div><div>As it turns out, fee-bidding =
+BMM can be achieved using only a covenant structure for transactions.[1]
+
+ You&#39;d have to create a sequence of transactions (one per block), to wh=
+ich a hash can be attached. These can simply be pre-signed transactions (re=
+quires forgetting a key, but the worst that can happen is that the chain ha=
+lts), or an actual covenant using either sighash_anyprevout or op_ctv (we d=
+on&#39;t have these yet) =E2=80=93 no specialized soft fork (or hard fork) =
+is required.</div><div><br></div><div>You might think any decentralized alt=
+ernative chain requires an altcoin, but this can also be avoided with a per=
+petual one-way peg.[2] For more details, I recommend watching this video of=
+ the full concept, which I call &quot;spacechains&quot;:=C2=A0<a href=3D"ht=
+tps://youtu.be/N2ow4Q34Jeg">https://youtu.be/N2ow4Q34Jeg</a></div><div><br>=
+</div><div>-- Ruben Somsen</div><div><br></div><div><br></div><div><br></di=
+v><div>[0] Blind Merged-Mining for Drivechains:=C2=A0<a href=3D"https://git=
+hub.com/bitcoin/bips/blob/master/bip-0301.mediawiki">https://github.com/bit=
+coin/bips/blob/master/bip-0301.mediawiki</a></div><div><br></div><div>[1] F=
+ee-bidding Blind Merged-Mining with covenants: <a href=3D"https://gist.gith=
+ub.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5">https://gist.github.co=
+m/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5</a></div><div><br></div><div=
+>[2] Perpetual one-way peg:=C2=A0<a href=3D"https://medium.com/@RubenSomsen=
+/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2=
+f8ac302">https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-si=
+dechains-the-perpetual-one-way-peg-96cb2f8ac302</a></div></div><br><div cla=
+ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 20=
+21 at 9:33 PM Kostas Karasavvas via bitcoin-dev &lt;<a href=3D"mailto:bitco=
+in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.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">Hi Christopher,<div><br></div><div>Some feedback:</div><div><b=
+r></div><div>&quot;OP_RETURN is limited to 40 bytes of data.&quot;</div><di=
+v>It is 80 bytes.</div><div><br></div><div>&quot;A future BIP proposing suc=
+h a layer two protocol will be forthcoming.&quot;</div><div>So what is this=
+ BIP about? Just saying that it would be a nice idea? This BIP should be th=
+e one that would go through this L2 suggestion. If one root OP_RETURN subst=
+itutes all the rest it should say how that would be done... where would the=
+ merkle proofs be stored, what are the trust assumptions=C2=A0that we need =
+to make, etc.</div><div><br></div><div>&quot;Objections to this proposal&qu=
+ot; section</div><div>I agree with others re hard-fork, which would be a go=
+od thing of course.=C2=A0 My main objection with this proposal is that I do=
+n&#39;t see a proposal. It seems like wishful thinking... if only we could =
+substitute all the OP_RETURNs with one :-)</div><div><br></div><div>We have=
+ to make sure that a proposal like this (L2, etc.) would make sure that the=
+re are incentives that justify the added complexity for the users. Multisig=
+ is not the only way data could be stored the wrong way; P2PK, P2PKH, P2SH,=
+ P2WPKH, P2WSH can also be used. If the incentives are not good enough peop=
+le would start using these UTXO-bloat-heavy alternatives.</div><div><br></d=
+iv><div>There are a multitude of L2&#39;s (kind-of) that do this &#39;aggre=
+gation&#39; of data hashes using merkle trees. Factom is adding a single=C2=
+=A0merkle root per bitcoin block for the millions upon millions of records =
+(of thousand of users) that they keep in their network. Opentimestamps, tie=
+rion, blockstacks and others do a similar thing. I have investigated severa=
+l of those in the past, for one of my projects, but I ended up using plain =
+old OP_RETURN because the overhead of their (L2-like) solution and trust as=
+sumptions where not to my liking; at least for my use case. They were prett=
+y solid/useful for other use cases.</div><div><br></div><div>Unless the pro=
+posed L2 is flexible/generic enough it would really prohibit this L2 innova=
+tion that OP_RETURN allowed (see above).=C2=A0</div><div><br></div><div><br=
+></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
+_attr">On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev=
+ &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
+ote 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 found here:=C2=A0<a href=3D"https://github.com/cgilliard/=
+bips/blob/notarization/bip-XXXX.mediawiki" target=3D"_blank">https://github=
+.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki</a><div><br></div>=
+<div>I&#39;m sending this email to start the discussion regarding this prop=
+osal. If there are any comments/suggestions, 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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
+><div dir=3D"ltr"><div><div>Konstantinos A. Karasavvas</div><div>Software A=
+rchitect, Blockchain Engineer, Researcher, Educator</div><div dir=3D"ltr"><=
+a href=3D"https://twitter.com/kkarasavvas" target=3D"_blank">https://twitte=
+r.com/kkarasavvas</a><br></div></div></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>
+
+--00000000000046772005c01cd908--
+