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

[Nick Gregory]

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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191226/8a3166d9/attachment.html>