Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1CE54C000A for ; 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 ; 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 ; 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 ; Fri, 16 Apr 2021 21:09:37 +0000 (UTC) Received: by mail-oi1-x22a.google.com with SMTP id m13so29177291oiw.13 for ; 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: In-Reply-To: From: Christopher Gilliard Date: Fri, 16 Apr 2021 21:09:25 +0000 Message-ID: To: Ruben Somsen Content-Type: multipart/alternative; boundary="000000000000af7a0505c01d65ac" X-Mailman-Approved-At: Fri, 16 Apr 2021 21:39:08 +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 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 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
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 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]

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.

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.

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=A0https://youtu.be/N2ow4Q34Jeg<= /a>



On Fri, Apr 16, 2021= at 9:33 PM Kostas Karasavvas via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hi Christopher,

Some feedba= ck:

"OP_RETURN is limited to 40 bytes of data= ."
It is 80 bytes.

"A future B= IP 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 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.

"Objections to = this proposal" section
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 :-)

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.

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.

Unless the proposed L2 is flexible/generic enough it would really prohibi= t this L2 innovation that OP_RETURN allowed (see above).=C2=A0


On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
Konstantinos A. Karasavvas
Software A= rchitect, Blockchain Engineer, Researcher, Educator
<= a href=3D"https://twitter.com/kkarasavvas" target=3D"_blank">https://twitte= r.com/kkarasavvas
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000af7a0505c01d65ac--