From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C0FB4C0881 for ; Thu, 26 Dec 2019 02:23:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id AB55284524 for ; Thu, 26 Dec 2019 02:23:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-MT_Y4IUtCj for ; Thu, 26 Dec 2019 02:23:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 60D4D84456 for ; Thu, 26 Dec 2019 02:23:24 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id d7so26442762otf.5 for ; Wed, 25 Dec 2019 18:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7aBFG5451OWzlwnj5ePrsMZt01l0SmoL7IXbdlDBLao=; b=OilqwQxLiXw7G6dBUaHoMwhtQzlPpeSjJZS+WvpHYrpr/PR3nRTOVbirw8g4W5yYbG GFKlTW9brwwPBuFDZqTnLHVkGqC/VMsZGcX+x1cpI/sTyOeghI0yWLTEeF6nTCICqMPj dU82aMRe2DCLVZ4055g/8EIgxofpu9Ykf4zqQt/k2sgV0rDS6XDFid96pveTI+BXVS1Y tJWrxWUO1Zuv6cWx6yXNiXBoKznI9Ntm9Qq3hdhnh+A07KcqsRHypHz4saXMaSHazTuZ e+Twkx7PhSFue8+M0At9VJj26L40udNd06oVvNRWQIDGfiOuho+PLuCrJIcEDIxIi8Ih eoLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7aBFG5451OWzlwnj5ePrsMZt01l0SmoL7IXbdlDBLao=; b=s4pJrPkJSW4Nw6S8njodl4QpLNuQ2o+Gt8iIWe7aBc/3udOaoiomHwKt+NJbu9IU0X 8dTZg057BB1pfvjDAyUPU+eJ+/9slW3Y1YIZmiWYuU73CxKI7aUuC013vj5n9qiNBtMJ H0dfGuErCWDzDk5dhL2xdeS6G5LM/0IwrYNTsg9YPpwJOCVUCbEhdil7ZsLe/SvKAsF8 jsKuJer8IrvwFw8zS3Gk/sQfrEvV8ScwvIQ51c290N+0sQnFKadGCzDpaUwhny97VU0V NikdFdWDX7Ggw35Ssz578h8JuV3gC9YZktj/yxJDakqnE6C3m6dqPcod5pwKUFNGjtuz AOFQ== X-Gm-Message-State: APjAAAVsUSN92+opcu2az8zq/3GqtncYpybzGydTGnAWkuvfprVLHRUK ygna/KrRW0rGgAROp0LHd9V2WtCdJ97BMdazCfZ4bCVt X-Google-Smtp-Source: APXvYqz7PExcCsRxG5y1iENA8Gm9IM2hBfy4d2xUbH5SkyrZ6cPKd3yN02gZeYhr2/6hukapBpeYL4hdBS+Z0gzrhwA= X-Received: by 2002:a05:6830:1141:: with SMTP id x1mr48722590otq.120.1577327003378; Wed, 25 Dec 2019 18:23:23 -0800 (PST) MIME-Version: 1.0 From: Ruben Somsen Date: Thu, 26 Dec 2019 03:23:10 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000bb268d059a920f03" X-Mailman-Approved-At: Thu, 26 Dec 2019 02:25:50 +0000 Subject: [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 02:23:25 -0000 --000000000000bb268d059a920f03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 capturing the fees inside the other blockchain. Since miners don=E2=80=99t have to kn= ow 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 adds 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 the 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 can generate the following without any 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 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-b= mm-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 into 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 hashrate and such. It seems inevitable 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. 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 immediate purpose. Given the lack of a block subsidy, there may not be enough impetus to move 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 100 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 answe= r, 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 meth= ods 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 and 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/msg08075= .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/0163= 52.html [5] https://twitter.com/lopp/status/1081558829454802945 --000000000000bb268d059a920f03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Blind Merged Mining (BMM) is the idea of committing the ha= sh 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 capturing the fees inside the other blockchain. Since miners don=E2=80= =99t have to know what the hash represents and are simply incentivized to c= hoose 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 Szt= orc, but required a specific soft fork. [0]

In essence, BMM is a mec= hanism that allows external blockchains (altcoins, tokens) to outsource the= ir mining to the Bitcoin blockchain. Instead of burning electricity with AS= ICs, they pay bitcoins to miners, who in turn will perform Proof-of-Work (P= oW) for the privilege of obtaining this payment. This increases the total P= oW on the Bitcoin blockchain, which adds to the security of the Bitcoin net= work. It's an easy consensus mechanism to implement, and simple to mine= , only requiring full node software for both chains and some bitcoins.
<= br>While it may be hard to justify this as a soft fork, it turns out that t= he inclusion of sighash_anyprevout (previously sighash_noinput) into Bitcoi= n is sufficient to make BMM work, because, as noted by Anthony Towns [1], s= ighash_anyprevout allows for the creation of op_checktemplateverify (op_ctv= , previously op_securethebag) style covenants [2]. With that, we can genera= te the following without any trusted setup:

- A long string of sigha= sh_anyprevout transactions, each only spendable by the next (the spending s= ignature is placed in the output script, making it a covenant)
- RBF ena= bled and signed with sighash flags single, anyonecanpay, and anyprevout, al= lowing 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 diagra= m can be found here:
https://gist.github.com/RubenSom= sen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(Note that op_= ctv instead of sighash_anyprevout would require the use of CPFP, because al= l outputs need to be pre-defined.)

This setup generates a unique loc= ation for the hash, which can be freely competed for by anyone with the hel= p 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 th= e 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 op= posite does not have to be true. This enables some interesting possibilitie= s. For instance, you could make a conditional BMM token transfer that only = goes through if a specific Bitcoin transaction occurs within a certain peri= od of time, thus enabling atomic swaps (especially useful when combined wit= h asset issuance/colored coins/pegged tokens). It would also be possible to= create contracts based on Bitcoin=E2=80=99s hashrate and such.

It s= eems inevitable that this chain will need some kind of native token in orde= r 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 tim= e 1 BTC can be burned for 1 token, essentially preserving the 21M coin limi= t. Coins that are burned will never return, benefiting all BTC holders equa= lly. Holding BTC will always be preferable, because the option to move is a= lways open to you. This should disincentivize speculation -- it only makes = sense to move coins if they serve an immediate purpose.

Given the la= ck of a block subsidy, there may not be enough impetus to move the chain fo= rward 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 ori= ginal chain is using. A 10-block reorg would take 100 minutes on average to= catch up, during which the original chain won=E2=80=99t move forward. If f= ee pressure of new transactions is targeted exclusively towards the origina= l chain during this time [4], there would be forward pressure that makes re= orgs more expensive. Whether this mitigation is sufficient is an open quest= ion.

Finally, it is worth asking whether BMM interferes too much wit= h the existing 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 already possible today. One could simply use up lots of block space ins= tead of specifying a unique location for the hash, as demonstrated by Verib= lock [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 methods= may be utilized instead.

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

- Since the exact signature is co= mmitted to ahead of time, private key security is actually irrelevant. You = can simply use G to replace both R and P instead of the usual s =3D r + e*p= . This means anyone can easily pre-compute all the sighash_anyprevout signa= tures 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 b= e made unusable 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 i= nternal taproot key T =3D H + hash(H||bmm_hash)*G.

-- Ruben Somsen

[0] https://github.com/bitcoin/bips/blob/master/bip-0301.mediawik= i

[1] https://www.mail-archive.com/bitcoin-dev= @lists.linuxfoundation.org/msg08075.html

[2] https://github.c= om/JeremyRubin/bips/blob/ctv-v2/bip-ctv.mediawiki

[3] https://blockstream.com/eltoo.pdf
[4] https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2018-September/016352.html

[5] https://twitter.com/lopp/status/1= 081558829454802945
--000000000000bb268d059a920f03--