Ruben Somsen [ARCHIVE] on Nostr: đź“… Original date posted:2019-12-26 đź“ť Original message:Hello Nick, Thank you for ...
đź“… Original date posted:2019-12-26
đź“ť Original message: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 at 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 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/3e453af7/attachment-0001.html>;
đź“ť Original message: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 at 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 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/3e453af7/attachment-0001.html>;