MIME-Version: 1.0
References: <CAPv7TjYb3u9wauHQ_U9tTRKotuJushnnoAGu-MLgA_djMkdNdw@mail.gmail.com>
 <CAEqdS56_LaRfGihpDy7U+F-2jSzFxCFwCnFztdo2Lze0Ot-Riw@mail.gmail.com>
In-Reply-To: <CAEqdS56_LaRfGihpDy7U+F-2jSzFxCFwCnFztdo2Lze0Ot-Riw@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Thu, 26 Dec 2019 17:52:43 +0100
Message-ID: <CAPv7TjY4sM=MxBfdATgkKNHTM4xnP=dCBnRZj0Oqh7KSapPUCg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000700888059a9e3559"
Subject: Re: [bitcoin-dev] Blind Merged Mining with covenants (
 sighash_anyprevout / op_ctv )
Precedence: list

--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 <nico.gregory@gmail.com> 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

<div dir=3D"ltr">Hello Nick,<div><br></div><div>Thank you for your interest=
.</div><div><br></div><div>It is quite different. Unlike MainStay, BMM isn&=
#39;t federation controlled. It&#39;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.</div><div><br></div><div>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&#39;ll have two chains t=
o worry about in terms of reorg potential (i.e. slow peg-outs).</div><div><=
br></div><div>Cheers,</div><div>Ruben</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 26, 2019 at 1:32 PM =
Nick Gregory &lt;<a href=3D"mailto:nico.gregory@gmail.com">nico.gregory@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>This not similar to MainS=
tay?</div><div><br></div><div><a href=3D"https://commerceblock.readthedocs.=
io/en/latest/mainstay/index.html" target=3D"_blank">https://commerceblock.r=
eadthedocs.io/en/latest/mainstay/index.html</a><br></div><div><br></div><di=
v><a href=3D"https://mainstay.xyz" target=3D"_blank">https://mainstay.xyz</=
a></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Thu, Dec 26, 2019 at 2:25 AM Ruben Somsen via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></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">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]<br><br>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&#39;s an easy cons=
ensus mechanism to implement, and simple to mine, only requiring full node =
software for both chains and some bitcoins.<br><br>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:<br><br>- 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)<br>- 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])<br>- A r=
elative locktime of one block, ensuring only one transaction gets mined per=
 block<br><br>A complete transaction flow diagram can be found here:<br><a =
href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a=
5#file-bmm-svg" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4be=
6d18e5fa526b17d8b34906b16a5#file-bmm-svg</a><br><br>(Note that op_ctv inste=
ad of sighash_anyprevout would require the use of CPFP, because all outputs=
 need to be pre-defined.)<br><br>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.<br><br>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.<br><br>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.<br><br>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><=
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.<br><br>Some technical details (thanks to Anthony Towns for=
 providing his insights):<br><br>- 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.<br><br>- 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.<br><br>-- Ruben Somsen<br><br><br=
>[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.mediaw=
iki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0301=
.mediawiki</a><br><br>[1] <a href=3D"https://www.mail-archive.com/bitcoin-d=
ev@lists.linuxfoundation.org/msg08075.html" target=3D"_blank">https://www.m=
ail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08075.html</a><br>=
<br>[2] <a href=3D"https://github.com/JeremyRubin/bips/blob/ctv-v2/bip-ctv.=
mediawiki" target=3D"_blank">https://github.com/JeremyRubin/bips/blob/ctv-v=
2/bip-ctv.mediawiki</a><br><br>[3] <a href=3D"https://blockstream.com/eltoo=
.pdf" target=3D"_blank">https://blockstream.com/eltoo.pdf</a><br><br>[4] <a=
 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Septe=
mber/016352.html" target=3D"_blank">https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2018-September/016352.html</a><br><br>[5] <a href=3D"https=
://twitter.com/lopp/status/1081558829454802945" target=3D"_blank">https://t=
witter.com/lopp/status/1081558829454802945</a><br></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>

--000000000000700888059a9e3559--