From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 03376C0881 for ; Thu, 26 Dec 2019 16:52:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id F02DE86C7A for ; Thu, 26 Dec 2019 16:52:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDnpyECYTjMi for ; Thu, 26 Dec 2019 16:52:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by hemlock.osuosl.org (Postfix) with ESMTPS id 93E7886C3A for ; Thu, 26 Dec 2019 16:52:56 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id c16so8751047oic.3 for ; Thu, 26 Dec 2019 08:52:56 -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=K1ZnE/yc2KdAjCXwRWlF8ecO8nmP/am5NNkEEJgzAkU=; b=FJlaAfTJwL6mGSjyXmEs2B7iz5jpgX/G4F1YN0t4cnrHxZBAxi9p0NBskcU3a6LQOs R33kMlDFAn8TSe9gjJ8wRRge8G810S8AglEFEK8/hvzNqPGV/U6a2BFgblVnZai82VZJ gfFpD81K1HbFKZAojKU2e/C+kFUZbR+jaiO8i5UlesANKai8oOV6ap2nyBx78tj1Shsl oM5bQzs8PB/zcejCDeE/cqmpOzH0P0djKCk7+lPGRq28gP1rgEwmJVL1Ec9aGFWGA8/x aykHx8Gl3pQuaKTCpQuGTycVb4og7tQy9806VKx0jfOZnIZk0FJUG/sFm4Vsv7K12RBm NaAA== 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=K1ZnE/yc2KdAjCXwRWlF8ecO8nmP/am5NNkEEJgzAkU=; b=GohJcyO9o2jILi/jwz87UrNWmboxVIe6DCmxf7gsWkC9xnhW8ihed99Ycj7zH7SXn9 4d2JGA5UCOdYkCNMgP8Kyd0Uchna70/dY6Lj44m1edea3o8FHJexzRObeOfpIRoy5EjU nHa1PDAcAze5ZcawgRklYSo3ZCKoZQ6jMmhqbhq6U5XCJHmKJhr5EPys4UjKmDX22BP7 g4GwlDvd7vAgXuFTtk31j/dg2+ZLaes+4LxAxV1bGnT9L7nHmbBkmeMbTVVm5HUqx4E2 xbCAWG0Yrkg4PE/6oddSH9oQDDSINv5qMphN7tq+o0LdLD8HR1f8Hflh+J1Ex2tt0hTc 8fIw== X-Gm-Message-State: APjAAAWMJ67yAlREWzVBqtvtVtVnfPAqXMaCBDjUegaxXzN5G7HjNXs5 x00jSqQFN0pb+knw7to3t/af7+1l/FEj/BrNgRelgOGZ X-Google-Smtp-Source: APXvYqyqN8gKuLL4oCs9QOCDLrnxP7AKKcz0ZALHYGLmZTC8KaK9O2BdPaza6xpQadPjBI0Y3d8ii8Qqrc26BbX3goc= X-Received: by 2002:aca:5d57:: with SMTP id r84mr2540588oib.42.1577379175597; Thu, 26 Dec 2019 08:52:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Thu, 26 Dec 2019 17:52:43 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000700888059a9e3559" X-Mailman-Approved-At: Thu, 26 Dec 2019 16:53:33 +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 16:52:58 -0000 --000000000000700888059a9e3559 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Nick, Thank you for your interest. It is quite different. Unlike MainStay, BMM isn't federation controlled. It's a decentralized consensus mechanism that can function entirely without a federation. BMM blocks are chosen by the highest bidder, which can be anyone. Note that it would be entirely possible for federations to issue two-way pegged tokens on this decentralized chain, but keep in mind you'll have two chains to worry about in terms of reorg potential (i.e. slow peg-outs). Cheers, Ruben On Thu, Dec 26, 2019 at 1:32 PM Nick Gregory wrote= : > 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 captur= ing >> 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, wh= ich >> 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 Tow= ns >> [1], sighash_anyprevout allows for the creation of op_checktemplateverif= y >> (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, maki= ng >> 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#fil= e-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 i= nto >> the fee paying output via taproot. If the block corresponding to the has= h >> is not revealed or invalid, then the BMM block simply gets orphaned, jus= t >> 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). I= t >> would also be possible to create contracts based on Bitcoin=E2=80=99s ha= shrate 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 preservin= g >> 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 immedi= ate >> 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 1= 00 >> 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 an= swer, but >> it should be noted that a much more inefficient version of BMM is alread= y >> 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 m= ethods 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 ke= y 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/msg08= 075.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/0= 16352.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 >> > --000000000000700888059a9e3559 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Nick,

Thank you for your interest= .

It is quite different. Unlike MainStay, BMM isn&= #39;t federation controlled. It's a decentralized consensus mechanism t= hat can function entirely without a federation. BMM blocks are chosen by th= e highest bidder, which can be anyone.

Note that i= t would be entirely possible for federations to issue two-way pegged tokens= on this decentralized chain, but keep in mind you'll have two chains t= o worry about in terms of reorg potential (i.e. slow peg-outs).
<= br>
Cheers,
Ruben

On Thu, Dec 26, 2019 at 1:32 PM = Nick Gregory <nico.gregory@gma= il.com> wrote:


On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Blind M= erged 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 i= nside the other blockchain. Since miners don=E2=80=99t have to know what th= e 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). T= his idea was originally conceived of by Paul Sztorc, but required a specifi= c soft fork. [0]

In essence, BMM is a mechanism that allows external= blockchains (altcoins, tokens) to outsource their mining to the Bitcoin bl= ockchain. Instead of burning electricity with ASICs, they pay bitcoins to m= iners, who in turn will perform Proof-of-Work (PoW) for the privilege of ob= taining this payment. This increases the total PoW on the Bitcoin blockchai= n, which adds to the security of the Bitcoin network. It's an easy cons= ensus 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_any= prevout (previously sighash_noinput) into Bitcoin is sufficient to make BMM= work, because, as noted by Anthony Towns [1], sighash_anyprevout allows fo= r the creation of op_checktemplateverify (op_ctv, previously op_securetheba= g) style covenants [2]. With that, we can generate the following without an= y trusted setup:

- A long string of sighash_anyprevout transactions,= each only spendable by the next (the spending signature is placed in the o= utput script, making it a covenant)
- RBF enabled and signed with sighas= h flags single, anyonecanpay, and anyprevout, allowing the addition of inpu= ts and outputs in order to pay fees (similar to fees in eltoo [3])
- A r= elative 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/5e4be= 6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(Note that op_ctv inste= ad 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 b= lock corresponding to the hash is not revealed or invalid, then the BMM blo= ck simply gets orphaned, just like in Sztorc=E2=80=99s proposal.

Whi= le the Bitcoin blockchain will be unaware of the BMM chain, the opposite do= es not have to be true. This enables some interesting possibilities. For in= stance, you could make a conditional BMM token transfer that only goes thro= ugh if a specific Bitcoin transaction occurs within a certain period of tim= e, thus enabling atomic swaps (especially useful when combined with asset i= ssuance/colored coins/pegged tokens). It would also be possible to create c= ontracts based on Bitcoin=E2=80=99s hashrate and such.

It seems inev= itable 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 c= an be burned for 1 token, essentially preserving the 21M coin limit. Coins = that are burned will never return, benefiting all BTC holders equally. Hold= ing BTC will always be preferable, because the option to move is always ope= n to you. This should disincentivize speculation -- it only makes sense to = move coins if they serve an immediate purpose.

Given the lack of a b= lock subsidy, there may not be enough impetus to move the chain forward ins= tead of enacting a reorg. However, BMM reorgs are somewhat unique in that t= hey will have to compete for the same unique location that the original cha= in 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 pressu= re of new transactions is targeted exclusively towards the original chain d= uring this time [4], there would be forward pressure that makes reorgs more= expensive. Whether this mitigation is sufficient is an open question.
<= br>Finally, it is worth asking whether BMM interferes too much with the exi= sting 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 alrea= dy possible today. One could simply use up lots of block space instead of s= pecifying a unique location for the hash, as demonstrated by Veriblock [5].= I therefore believe that the same argument as adding data via op_return ap= plies here -- if it=E2=80=99s not supported, more wasteful methods may be u= tilized instead.

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

- Since the exact signature is committed t= o ahead of time, private key security is actually irrelevant. You can simpl= y use G to replace both R and P instead of the usual s =3D r + e*p. This me= ans anyone can easily pre-compute all the sighash_anyprevout signatures wit= h s =3D 1 + e.

- Assuming taproot, the spending script will be insid= e a taproot leaf, meaning there is a key spend path which should be made un= usable in order to enforce the covenant. This can be achieved with a NUMS s= uch as hashToCurve(G) =3D =C2=A0H, which can then be used as the internal t= aproot 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.m= ail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08075.html
=
[2] https://github.com/JeremyRubin/bips/blob/ctv-v= 2/bip-ctv.mediawiki

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

[4] https://lists.linuxfoundation.org/piper= mail/bitcoin-dev/2018-September/016352.html

[5] https://t= witter.com/lopp/status/1081558829454802945
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000700888059a9e3559--