diff options
| author | Christopher Gilliard <christopher.gilliard@gmail.com> | 2021-04-16 21:09:25 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-16 21:09:41 +0000 |
| commit | d20852b33af156b1dcff99a4390a488601eedee0 (patch) | |
| tree | f6b2d8f77c7427820d547daec52e34e2761cd546 | |
| parent | 878692ae020d2052cec4b11dcef903800c966794 (diff) | |
| download | pi-bitcoindev-d20852b33af156b1dcff99a4390a488601eedee0.tar.gz pi-bitcoindev-d20852b33af156b1dcff99a4390a488601eedee0.zip | |
Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
| -rw-r--r-- | c1/6b4e80556568d1eeb88016274c7b83ad792197 | 341 |
1 files changed, 341 insertions, 0 deletions
diff --git a/c1/6b4e80556568d1eeb88016274c7b83ad792197 b/c1/6b4e80556568d1eeb88016274c7b83ad792197 new file mode 100644 index 000000000..300440c6b --- /dev/null +++ b/c1/6b4e80556568d1eeb88016274c7b83ad792197 @@ -0,0 +1,341 @@ +Return-Path: <christopher.gilliard@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 1CE54C000A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 16 Apr 2021 21:09:41 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id F2476405AF + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 16 Apr 2021 21:09:40 +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 FEwe6HppjMhx + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 16 Apr 2021 21:09:37 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com + [IPv6:2607:f8b0:4864:20::22a]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 198924051F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 16 Apr 2021 21:09:37 +0000 (UTC) +Received: by mail-oi1-x22a.google.com with SMTP id m13so29177291oiw.13 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 16 Apr 2021 14:09:36 -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=+PIKlfEcaCTFNQMfCRcfCq8p08tIMtlm6jS8piWNJqY=; + b=OYTR1gFwxBjaBOy/jZFUtQca00q1xEMQxz6Vlp8Z0C1KdGwZ1Q104aApGnAZxaoJYj + EzzWVL6ubPfz1BURBpGPFBARHV9DVvoo2+3YrXPpzTuOPM7LzRCFFm1rWaa2IPjvYB0s + g6T1lTelNC8AEnSIaqnVM2QLBuhHIahMunaEa666dFGrkc95GGXcx261/VCTkRb93VRO + SfxIjvybRXIqYdcXYhoI8t8oPsQ3619rtNFpIII/ywyOrkPQSeVblUOghnCOb0Js3BS6 + O8+em/l6FjzUZRwvJVrOka6/gRGn1SNza2Pd5uLAE+G3Gctr6ucMmbCkcVMef4cjaq2B + uoiQ== +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=+PIKlfEcaCTFNQMfCRcfCq8p08tIMtlm6jS8piWNJqY=; + b=NSYwpYLA/jc+RXTLrWLJ7BsAgJiNpwcVHQwc64oHeSDHSkRX7DKrtF4FDUjqhnRG1m + tG1IZY3ritvyi7EBXO6bALerDxz7vvF5lXezqwHKZ0j3wMP6sM9czdUS/ETQ7fo1iGeN + KbiEqOCe2Fa8cG6vHRy/2uxIQmRiineWnkBc8k5Mt541caeIkkK21n+uuig/ccnWv9qa + UcByKgye7nBWq9RAL6VEK16tYIuat78796asP0VNbXI2LQW1SAnCLfD23czpgP8SNhfE + vn5vkMtMFii+6XXWB37zfOO7f2PtEIzBphnqzrIrtD1Rilv+kJgo4GC5kjzb18zvSkZh + pqHQ== +X-Gm-Message-State: AOAM531YHb938YVwnvovafz1EkP6+4G98rukfM/oeHNIng8Z26VgkyrD + t+dyUv1yeNqZzW7RMuSz/Vn191IXnNC5b2B7eYg= +X-Google-Smtp-Source: ABdhPJw6gw26AjUygVQv6jtqYHPdIs05ZZzInQIxgRUqW1toBHCKXD6MFh/A5+MKMu5ZF4I/DrGyDlyVufzzQuliMj0= +X-Received: by 2002:a05:6808:4c4:: with SMTP id + a4mr8145119oie.170.1618607376135; + Fri, 16 Apr 2021 14:09:36 -0700 (PDT) +MIME-Version: 1.0 +References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com> + <CABE6yHscUPAcyK58DvqhOnxSOoPMBAy9aMUmReJYSkBit-Mekg@mail.gmail.com> + <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com> +In-Reply-To: <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com> +From: Christopher Gilliard <christopher.gilliard@gmail.com> +Date: Fri, 16 Apr 2021 21:09:25 +0000 +Message-ID: <CAK=nyAynHnv_WmgkZecCXBGdJCbZ1s3jJf66g0gTSf8oJnH7ZA@mail.gmail.com> +To: Ruben Somsen <rsomsen@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000af7a0505c01d65ac" +X-Mailman-Approved-At: Fri, 16 Apr 2021 21:39:08 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 21:09:41 -0000 + +--000000000000af7a0505c01d65ac +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks for the feedback. I will take at the links and the video and see if +there's anything that I can incorporate to the BIPs. + +On Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen <rsomsen@gmail.com> wrote: + +> 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 wor= +st +> 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 n= +o +> 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 cal= +l +> "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-sidechain= +s-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? Thi= +s +>> BIP should be the one that would go through this L2 suggestion. If one r= +oot +>> 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 sur= +e +>> that there are incentives that justify the added complexity for the user= +s. +>> 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 g= +ood +>> enough people would start using these UTXO-bloat-heavy alternatives. +>> +>> There are a multitude of L2's (kind-of) that do this 'aggregation' of +>> data hashes using merkle trees. Factom is adding a single merkle root pe= +r +>> 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 o= +f +>> those in the past, for one of my projects, but I ended up using plain ol= +d +>> 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 +>> prohibit 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 +>> +> + +--000000000000af7a0505c01d65ac +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Thanks for the feedback. I will take at the links and the = +video and see if there's anything that I can incorporate to the BIPs.</= +div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On= + Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen <<a href=3D"mailto:rsomsen@gm= +ail.com">rsomsen@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma= +il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= +04,204);padding-left:1ex"><div dir=3D"ltr">Hi Chris,<div><br></div><div>I a= +gree 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-b= +idding Blind Merged-Mining" (BMM), which as far as I know was first pr= +oposed by Paul Storc for Drivechains.[0]</div><div><br></div><div>If only o= +ne 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 Bitcoi= +n miners do not have to be aware of this other chain ("blind"). T= +here are also non fee-bidding variants that function e.g. by burning or loc= +king 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 structu= +re 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" target=3D"_blank">https://youtu.be/N2ow4Q34Jeg<= +/a></div><div><br></div><div>-- Ruben Somsen</div><div><br></div><div><br><= +/div><div><br></div><div>[0] Blind Merged-Mining for Drivechains:=C2=A0<a h= +ref=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki" targ= +et=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0301.mediawik= +i</a></div><div><br></div><div>[1] Fee-bidding Blind Merged-Mining with cov= +enants: <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d= +8b34906b16a5" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4be6d= +18e5fa526b17d8b34906b16a5</a></div><div><br></div><div>[2] Perpetual one-wa= +y peg:=C2=A0<a href=3D"https://medium.com/@RubenSomsen/21-million-bitcoins-= +to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302" target=3D"_b= +lank">https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidec= +hains-the-perpetual-one-way-peg-96cb2f8ac302</a></div></div><br><div class= +=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021= + at 9:33 PM Kostas Karasavvas via bitcoin-dev <<a href=3D"mailto:bitcoin= +-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo= +undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= +g-left:1ex"><div dir=3D"ltr">Hi Christopher,<div><br></div><div>Some feedba= +ck:</div><div><br></div><div>"OP_RETURN is limited to 40 bytes of data= +."</div><div>It is 80 bytes.</div><div><br></div><div>"A future B= +IP proposing such 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 the one that would go through this L2 suggestion. If one root= + 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=C2= +=A0that we need to make, etc.</div><div><br></div><div>"Objections to = +this proposal" section</div><div>I agree with others re hard-fork, whi= +ch would be a good thing of course.=C2=A0 My main objection with this propo= +sal is that I don't see a proposal. It seems like wishful thinking... i= +f 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 ma= +ke 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; P2= +PK, P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not = +good enough people would start using these UTXO-bloat-heavy alternatives.</= +div><div><br></div><div>There are a multitude of L2's (kind-of) that do= + this 'aggregation' of data hashes using merkle trees. Factom is ad= +ding a single=C2=A0merkle root per bitcoin block for the millions upon mill= +ions of records (of thousand of users) that they keep in their network. Ope= +ntimestamps, tierion, blockstacks and others do a similar thing. I have inv= +estigated 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) solut= +ion and trust assumptions where not to my liking; at least for my use case.= + They were pretty solid/useful for other use cases.</div><div><br></div><di= +v>Unless the proposed L2 is flexible/generic enough it would really prohibi= +t this L2 innovation that OP_RETURN allowed (see above).=C2=A0</div><div><b= +r></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.or= +g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<b= +r></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 found here:=C2=A0<a href=3D"https://githu= +b.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 reg= +arding this proposal. 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> +</blockquote></div> + +--000000000000af7a0505c01d65ac-- + |