From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9C9D0C0881 for ; Thu, 26 Dec 2019 12:32:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7D91220368 for ; Thu, 26 Dec 2019 12:32:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75k4E2Y7j8WW for ; Thu, 26 Dec 2019 12:32:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by silver.osuosl.org (Postfix) with ESMTPS id 634372014B for ; Thu, 26 Dec 2019 12:32:38 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id c16so21704801ioh.6 for ; Thu, 26 Dec 2019 04:32:38 -0800 (PST) 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=QK1Rj35PX1tHQZSZK1Vd+rfo0BiJSh9lLGt6yWQVDrE=; b=bCXbJwWyz90qtWwKtpi8Am3ql9Zsy3w60X6ILcVoIez0dsjg4wGGOkGF0dGuliawaY 5HLxGN5tnsk0B+xITKZiJXrBCFcbJAlpggg2wTs3IpuJ2bQmpP6UNRuVZgP2fuUI2Efq ForKnCF01J/Yp0zVVM3wmZjR2i7kdZoDojOaHXVGYGhctQ6Zdt1/FW/SJDhpPcSjFZd4 fDisazFnJbROiOdqN1eVpCcEO4j5YGEEnN7MY4/cNJJjOk288XoR66mGzlLsLpCEi2g7 JVNTA1aUmYkhK9RL5Je/u2Aqe7XLhiG89TSeJ2Ob+w76/eKjgaSM/1I2Wy/iEymxYxyf qgKA== 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=QK1Rj35PX1tHQZSZK1Vd+rfo0BiJSh9lLGt6yWQVDrE=; b=IxcfzfCtCFtoenIy2wap3uzwc9Vkf5bZasPSGXrnncjg0FN0DDd2v7cREkdYuBDhJ/ Q4q2cakTwavo7nA46P91jo1QkAE34zwr2teih8i62Vipx5hUBht9FkYJ/m+zHX/Jj/hy q/JSUKv0swXKIC7yujZklvXJhnsh0spfvbaJLWx6EzUAuYpGEStRvDq65T9108+rVGqG adEAwcSA0XLMTfbNJ4qmklXJ2YFQJMpSz0/V12hKJYzKhGDffwBJhjfKRCdvMfhyfN0F gFplFCynNloX5Pp8oBmP4BKtOCrFa7neMRk1Ra7xW3sMEwvi+4xpdYL6ihtQwTq2Vii0 kzcQ== X-Gm-Message-State: APjAAAWrXDRFcSKK9IZtsfpo5BN61+iED9UGl+WUaE+XW/QqYqpoFXU3 2tikvbDhV3CxTdYO11/Bejt6dS8OqeN6/id7UnM= X-Google-Smtp-Source: APXvYqwS0C5RlYEkFbVCt2hM6cA1QXmNvA9s8VtBLAlN2GSlpIEdSowKByOoXqXMzscezsax+M5XCGU0H2Jy1aqFdwo= X-Received: by 2002:a5d:87c8:: with SMTP id q8mr32671347ios.108.1577363557524; Thu, 26 Dec 2019 04:32:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Gregory Date: Thu, 26 Dec 2019 12:32:26 +0000 Message-ID: To: Ruben Somsen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000872841059a9a9266" X-Mailman-Approved-At: Thu, 26 Dec 2019 16:28:11 +0000 Subject: Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv ) 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: Thu, 26 Dec 2019 12:32:41 -0000 --000000000000872841059a9a9266 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This not similar to MainStay? https://commerceblock.readthedocs.io/en/latest/mainstay/index.html https://mainstay.xyz On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Blind Merged Mining (BMM) is the idea of committing the hash of another > blockchain into a unique location on the Bitcoin blockchain, and paying a > Bitcoin fee to miners for the privilege of deciding this hash and capturi= ng > the fees inside the other blockchain. Since miners don=E2=80=99t have to = know what > the hash represents and are simply incentivized to choose the highest > bidder, it requires no extra validation on their part (=E2=80=9Cblind=E2= =80=9D). This idea > was originally conceived of by Paul Sztorc, but required a specific soft > fork. [0] > > In essence, BMM is a mechanism that allows external blockchains (altcoins= , > tokens) to outsource their mining to the Bitcoin blockchain. Instead of > burning electricity with ASICs, they pay bitcoins to miners, who in turn > will perform Proof-of-Work (PoW) for the privilege of obtaining this > payment. This increases the total PoW on the Bitcoin blockchain, which ad= ds > to the security of the Bitcoin network. It's an easy consensus mechanism = to > implement, and simple to mine, only requiring full node software for both > chains and some bitcoins. > > While it may be hard to justify this as a soft fork, it turns out that th= e > inclusion of sighash_anyprevout (previously sighash_noinput) into Bitcoin > is sufficient to make BMM work, because, as noted by Anthony Towns [1], > sighash_anyprevout allows for the creation of op_checktemplateverify > (op_ctv, previously op_securethebag) style covenants [2]. With that, we c= an > generate the following without any trusted setup: > > - A long string of sighash_anyprevout transactions, each only spendable b= y > the next (the spending signature is placed in the output script, making i= t > a covenant) > - RBF enabled and signed with sighash flags single, anyonecanpay, and > anyprevout, allowing the addition of inputs and outputs in order to pay > fees (similar to fees in eltoo [3]) > - A relative locktime of one block, ensuring only one transaction gets > mined per block > > A complete transaction flow diagram can be found here: > > https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file= -bmm-svg > > (Note that op_ctv instead of sighash_anyprevout would require the use of > CPFP, because all outputs need to be pre-defined.) > > This setup generates a unique location for the hash, which can be freely > competed for by anyone with the help of RBF. The hash can be committed in= to > the fee paying output via taproot. If the block corresponding to the hash > is not revealed or invalid, then the BMM block simply gets orphaned, just > like in Sztorc=E2=80=99s proposal. > > While the Bitcoin blockchain will be unaware of the BMM chain, the > opposite does not have to be true. This enables some interesting > possibilities. For instance, you could make a conditional BMM token > transfer that only goes through if a specific Bitcoin transaction occurs > within a certain period of time, thus enabling atomic swaps (especially > useful when combined with asset issuance/colored coins/pegged tokens). It > would also be possible to create contracts based on Bitcoin=E2=80=99s has= hrate and > such. > > It seems inevitable that this chain will need some kind of native token i= n > order to pay for fees. This makes me uneasy. The fairest and least > speculation-inducing method I can think of is a perpetual one-way peg, > where at any time 1 BTC can be burned for 1 token, essentially preserving > the 21M coin limit. Coins that are burned will never return, benefiting a= ll > BTC holders equally. Holding BTC will always be preferable, because the > option to move is always open to you. This should disincentivize > speculation -- it only makes sense to move coins if they serve an immedia= te > purpose. > > Given the lack of a block subsidy, there may not be enough impetus to mov= e > the chain forward instead of enacting a reorg. However, BMM reorgs are > somewhat unique in that they will have to compete for the same unique > location that the original chain is using. A 10-block reorg would take 10= 0 > minutes on average to catch up, during which the original chain won=E2=80= =99t move > forward. If fee pressure of new transactions is targeted exclusively > towards the original chain during this time [4], there would be forward > pressure that makes reorgs more expensive. Whether this mitigation is > sufficient is an open question. > > Finally, it is worth asking whether BMM interferes too much with the > existing incentive structure of Bitcoin. I don=E2=80=99t have a clear ans= wer, but > it should be noted that a much more inefficient version of BMM is already > possible today. One could simply use up lots of block space instead of > specifying a unique location for the hash, as demonstrated by Veriblock > [5]. I therefore believe that the same argument as adding data via > op_return applies here -- if it=E2=80=99s not supported, more wasteful me= thods may > be utilized instead. > > Some technical details (thanks to Anthony Towns for providing his > insights): > > - Since the exact signature is committed to ahead of time, private key > security is actually irrelevant. You can simply use G to replace both R a= nd > P instead of the usual s =3D r + e*p. This means anyone can easily > pre-compute all the sighash_anyprevout signatures with s =3D 1 + e. > > - Assuming taproot, the spending script will be inside a taproot leaf, > meaning there is a key spend path which should be made unusable in order = to > enforce the covenant. This can be achieved with a NUMS such as > hashToCurve(G) =3D H, which can then be used as the internal taproot key= T =3D > H + hash(H||bmm_hash)*G. > > -- Ruben Somsen > > > [0] https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki > > [1] > https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg080= 75.html > > [2] https://github.com/JeremyRubin/bips/blob/ctv-v2/bip-ctv.mediawiki > > [3] https://blockstream.com/eltoo.pdf > > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/01= 6352.html > > [5] https://twitter.com/lopp/status/1081558829454802945 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000872841059a9a9266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Dec 26, 2019 at 2:25 AM = Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Blind = Merged Mining (BMM) is the idea of committing the hash of another blockchai= n into a unique location on the Bitcoin blockchain, and paying a Bitcoin fe= e to miners for the privilege of deciding this hash and capturing the fees = inside the other blockchain. Since miners don=E2=80=99t have to know what t= he hash represents and are simply incentivized to choose the highest bidder= , it requires no extra validation on their part (=E2=80=9Cblind=E2=80=9D). = This idea was originally conceived of by Paul Sztorc, but required a specif= ic soft fork. [0]

In essence, BMM is a mechanism that allows externa= l blockchains (altcoins, tokens) to outsource their mining to the Bitcoin b= lockchain. Instead of burning electricity with ASICs, they pay bitcoins to = miners, who in turn will perform Proof-of-Work (PoW) for the privilege of o= btaining this payment. This increases the total PoW on the Bitcoin blockcha= in, which adds to the security of the Bitcoin network. It's an easy con= sensus mechanism to implement, and simple to mine, only requiring full node= software for both chains and some bitcoins.

While it may be hard to= justify this as a soft fork, it turns out that the inclusion of sighash_an= yprevout (previously sighash_noinput) into Bitcoin is sufficient to make BM= M work, because, as noted by Anthony Towns [1], sighash_anyprevout allows f= or the creation of op_checktemplateverify (op_ctv, previously op_securetheb= ag) style covenants [2]. With that, we can generate the following without a= ny trusted setup:

- A long string of sighash_anyprevout transactions= , each only spendable by the next (the spending signature is placed in the = output script, making it a covenant)
- RBF enabled and signed with sigha= sh flags single, anyonecanpay, and anyprevout, allowing the addition of inp= uts and outputs in order to pay fees (similar to fees in eltoo [3])
- A = relative locktime of one block, ensuring only one transaction gets mined pe= r block

A complete transaction flow diagram can be found here:
https://gist.github.com/RubenSomsen/5e4b= e6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(Note that op_ctv inst= ead of sighash_anyprevout would require the use of CPFP, because all output= s need to be pre-defined.)

This setup generates a unique location fo= r the hash, which can be freely competed for by anyone with the help of RBF= . The hash can be committed into the fee paying output via taproot. If the = block corresponding to the hash is not revealed or invalid, then the BMM bl= ock simply gets orphaned, just like in Sztorc=E2=80=99s proposal.

Wh= ile the Bitcoin blockchain will be unaware of the BMM chain, the opposite d= oes not have to be true. This enables some interesting possibilities. For i= nstance, you could make a conditional BMM token transfer that only goes thr= ough if a specific Bitcoin transaction occurs within a certain period of ti= me, thus enabling atomic swaps (especially useful when combined with asset = issuance/colored coins/pegged tokens). It would also be possible to create = contracts based on Bitcoin=E2=80=99s hashrate and such.

It seems ine= vitable that this chain will need some kind of native token in order to pay= for fees. This makes me uneasy. The fairest and least speculation-inducing= method I can think of is a perpetual one-way peg, where at any time 1 BTC = can be burned for 1 token, essentially preserving the 21M coin limit. Coins= that are burned will never return, benefiting all BTC holders equally. Hol= ding BTC will always be preferable, because the option to move is always op= en to you. This should disincentivize speculation -- it only makes sense to= move coins if they serve an immediate purpose.

Given the lack of a = block subsidy, there may not be enough impetus to move the chain forward in= stead of enacting a reorg. However, BMM reorgs are somewhat unique in that = they will have to compete for the same unique location that the original ch= ain is using. A 10-block reorg would take 100 minutes on average to catch u= p, during which the original chain won=E2=80=99t move forward. If fee press= ure of new transactions is targeted exclusively towards the original chain = during this time [4], there would be forward pressure that makes reorgs mor= e expensive. Whether this mitigation is sufficient is an open question.
=
Finally, it is worth asking whether BMM interferes too much with the ex= isting incentive structure of Bitcoin. I don=E2=80=99t have a clear answer,= but it should be noted that a much more inefficient version of BMM is alre= ady possible today. One could simply use up lots of block space instead of = specifying a unique location for the hash, as demonstrated by Veriblock [5]= . I therefore believe that the same argument as adding data via op_return a= pplies here -- if it=E2=80=99s not supported, more wasteful methods may be = utilized instead.

Some technical details (thanks to Anthony Towns fo= r providing his insights):

- Since the exact signature is committed = to ahead of time, private key security is actually irrelevant. You can simp= ly use G to replace both R and P instead of the usual s =3D r + e*p. This m= eans anyone can easily pre-compute all the sighash_anyprevout signatures wi= th s =3D 1 + e.

- Assuming taproot, the spending script will be insi= de a taproot leaf, meaning there is a key spend path which should be made u= nusable in order to enforce the covenant. This can be achieved with a NUMS = such as hashToCurve(G) =3D =C2=A0H, which can then be used as the internal = taproot key T =3D H + hash(H||bmm_hash)*G.

-- Ruben Somsen

[0] https://github.com/bitcoin/bips/blob/master/bip-030= 1.mediawiki

[1] https://www.= mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08075.html
[2] https://github.com/JeremyRubin/bips/blob/ctv-= v2/bip-ctv.mediawiki

[3] https://blockstream.com/eltoo.pdf

[4] <= a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Sept= ember/016352.html" target=3D"_blank">https://lists.linuxfoundation.org/pipe= rmail/bitcoin-dev/2018-September/016352.html

[5] https://= twitter.com/lopp/status/1081558829454802945
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000872841059a9a9266--