MIME-Version: 1.0
References: <CAPv7TjYb3u9wauHQ_U9tTRKotuJushnnoAGu-MLgA_djMkdNdw@mail.gmail.com>
In-Reply-To: <CAPv7TjYb3u9wauHQ_U9tTRKotuJushnnoAGu-MLgA_djMkdNdw@mail.gmail.com>
From: Nick Gregory <nico.gregory@gmail.com>
Date: Thu, 26 Dec 2019 12:32:26 +0000
Message-ID: <CAEqdS56_LaRfGihpDy7U+F-2jSzFxCFwCnFztdo2Lze0Ot-Riw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000872841059a9a9266"
Subject: Re: [bitcoin-dev] Blind Merged Mining with covenants (
 sighash_anyprevout / op_ctv )
Precedence: list

--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

<div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature"><div>This not similar to MainStay?</div><div><br><=
/div><div><a href=3D"https://commerceblock.readthedocs.io/en/latest/mainsta=
y/index.html">https://commerceblock.readthedocs.io/en/latest/mainstay/index=
.html</a><br></div><div><br></div><div><a href=3D"https://mainstay.xyz">htt=
ps://mainstay.xyz</a></div></div></div><br></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 26, 2019 at 2:25 AM =
Ruben Somsen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">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]<br><br>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&#39;s an easy con=
sensus 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_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:<br><br>- 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)<br>- 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])<br>- A =
relative locktime of one block, ensuring only one transaction gets mined pe=
r block<br><br>A complete transaction flow diagram can be found here:<br><a=
 href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16=
a5#file-bmm-svg" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4b=
e6d18e5fa526b17d8b34906b16a5#file-bmm-svg</a><br><br>(Note that op_ctv inst=
ead of sighash_anyprevout would require the use of CPFP, because all output=
s need to be pre-defined.)<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br>=
<br>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.<br><br>Some technical details (thanks to Anthony Towns fo=
r providing his insights):<br><br>- 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.<br><br>- 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.<br><br>-- Ruben Somsen<br><br><b=
r>[0] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.media=
wiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-030=
1.mediawiki</a><br><br>[1] <a href=3D"https://www.mail-archive.com/bitcoin-=
dev@lists.linuxfoundation.org/msg08075.html" target=3D"_blank">https://www.=
mail-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-=
v2/bip-ctv.mediawiki</a><br><br>[3] <a href=3D"https://blockstream.com/elto=
o.pdf" target=3D"_blank">https://blockstream.com/eltoo.pdf</a><br><br>[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</a><br><br>[5] <a href=3D"http=
s://twitter.com/lopp/status/1081558829454802945" target=3D"_blank">https://=
twitter.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>

--000000000000872841059a9a9266--