path: root/15/121b2caa6f27bb4e1f72ef0d4cf06e1e79421f

Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 03376C0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Dec 2019 16:52:56 +0000 (UTC)
Received: by mail-oi1-f196.google.com with SMTP id c16so8751047oic.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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--