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.greg...@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 >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
