[bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[Ruben Somsen]

[-- Attachment #1: Type: text/plain, Size: 5945 bytes --]

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’t have to know what
the hash represents and are simply incentivized to choose the highest
bidder, it requires no extra validation on their part (“blind”). 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-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 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’s 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’s 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’t 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’t 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 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’s 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 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 = r + e*p. This means anyone can easily
pre-compute all the sighash_anyprevout signatures with s = 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) =  H, which can then be used as the internal taproot key T =
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/016352.html

[5] https://twitter.com/lopp/status/1081558829454802945

[-- Attachment #2: Type: text/html, Size: 6555 bytes --]

Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[Nick Gregory]

[-- Attachment #1: Type: text/plain, Size: 6588 bytes --]

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 capturing
> the fees inside the other blockchain. Since miners don’t have to know what
> the hash represents and are simply incentivized to choose the highest
> bidder, it requires no extra validation on their part (“blind”). 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-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 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’s 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’s 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’t 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’t 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 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’s 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 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 = r + e*p. This means anyone can easily
> pre-compute all the sighash_anyprevout signatures with s = 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) =  H, which can then be used as the internal taproot key T =
> 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/016352.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
>

[-- Attachment #2: Type: text/html, Size: 7845 bytes --]

Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

[Ruben Somsen]

[-- Attachment #1: Type: text/plain, Size: 7332 bytes --]

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 capturing
>> the fees inside the other blockchain. Since miners don’t have to know what
>> the hash represents and are simply incentivized to choose the highest
>> bidder, it requires no extra validation on their part (“blind”). 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-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 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’s 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’s 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’t 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’t 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 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’s 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 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 = r + e*p. This means anyone can easily
>> pre-compute all the sighash_anyprevout signatures with s = 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) =  H, which can then be used as the internal taproot key T =
>> 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/016352.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
>>
>

[-- Attachment #2: Type: text/html, Size: 8824 bytes --]