Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )
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 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
Re: [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )
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 addi
