diff options
author | Ruben Somsen <rsomsen@gmail.com> | 2021-04-16 22:30:06 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-16 20:30:26 +0000 |
commit | 25f3a7fa880c457a92179e6c68eddbbf46390ae8 (patch) | |
tree | c08498ce3138d9c95c75bbd23428ae26edb74d20 | |
parent | b6e8b27c2c6b39c0fb7c5ba29fcd00be422b9a94 (diff) | |
download | pi-bitcoindev-25f3a7fa880c457a92179e6c68eddbbf46390ae8.tar.gz pi-bitcoindev-25f3a7fa880c457a92179e6c68eddbbf46390ae8.zip |
Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
-rw-r--r-- | e6/a14c84600f36be7256912989585ec3a402acf5 | 317 |
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 "fee-bidding Blind Merged-Mining= +" (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= + ("fee-bidding"). This hash can then be used to create another ch= +ain ("merged-mining"), while the Bitcoin miners do not have to be= + aware of this other chain ("blind"). 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'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'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 "spacechains":=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 <<a href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>= +> 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>"OP_RETURN is limited to 40 bytes of data."</div><di= +v>It is 80 bytes.</div><div><br></div><div>"A future BIP proposing suc= +h a layer two protocol will be forthcoming."</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>"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'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's (kind-of) that do this 'aggre= +gation' 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= + <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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-- + |