BIP 301: Blind Merged Mining (Consensus layer) #643
Seems reasonable to just merge with a "received only limited feedback, which was largely left unaddressed" header tag.…
On February 4, 2018 2:44:03 AM UTC, Paul Sztorc ***@***.***> wrote: This is a draft of a bip for blind merged mining, the second of two drivechain bips. You can view, comment on, or merge this pull request online at: #643 -- Commit Summary -- * Create images.txt * Add files via upload * Add files via upload * Add files via upload * Delete bip-hashrate-escrows.md * Delete images.txt * Delete two-groups.png -- File Changes -- A bip-blind-merged-mining.md (329) A bip-blind-merged-mining/bmm-dots-examples.png (0) A bip-blind-merged-mining/images.txt (1) A bip-blind-merged-mining/witness-vs-critical.png (0) -- Patch Links -- https://github.com/bitcoin/bips/pull/643.patch https://github.com/bitcoin/bips/pull/643.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #643
luke-jr left a comment
BIPs are Mediawiki format, not Markdown.
This fails to address backward compatibility.
Furthermore, the spec itself seems strictly inferior to the older merge mining protocol as used by Namecoin etc. The alleged shortcomings this BIP claims the older protocol has, are not in fact true.
Some actual shortcomings in this BIP:
These shortcomings are not even issues that I feel strongly about. But they are issues which are constantly raised by Matt Corallo and Peter Todd specifically. They are in Section 4.3 of Blockstream's sidechains whitepaper as well as in this podcast.
I feel that pool operators will just run all of these nodes from a safe place, and then send as little data as possible to the hashers (the physical ASICs). Perhaps you agree with me, but other people don't agree with us!!
Of course, we can have sidechains of sidechains, so the real number is unlimited. And we could simply soft fork BMM into the mainchain a second time (for example to add 256 more).
I really do not think there will be more than 256, but I suppose we can't know for sure.
You may have misunderstood the intent here. It is all about creating the conditions for M8, which is the way that sidechain nodes "buy" space in the main:coinbase_txn . To do this, the M8 payment must trigger on something. In fact, we have two possible versions of M8. One triggers on prev, the other on skip count. The ideal M8 payment is M8_v2 a lightning network payment that triggers on prev. But when we need to resort to an on-chain txn then we must use M8_v1. M8_v1, however, unlike the LN payment, can trigger using the index. It actually saves 30 bytes (although the LN txn is better because it uses zero on-chain bytes).
There are a few reasons why this is a good idea. One is that, if miners do not support a sidechain, it is in danger of having its funds lost, trapped, or stolen. Another is that is not a big deal, because we expect profit-seeking miners to want to add sidechains, as these increase the value of mined BTC as well as miner's total tx-fee revenues.
More important reasons are here: http://www.drivechain.info/faq/#categorical-control
All of the data here is mandatory, so a merkle tree would only accomplish two things (as I see it): first, it would waste 32 bytes of space, to accommodate the (pointless) root hash ; and second, it would be a SegWit-like "evil fork" increasing the blocksize limit arbitrarily (or, I suppose, by 32*256 = 8192 bytes).
This is a disadvantage of this proposal, yes. But the database is pretty small, if you ask me.
I feel that the asymmetric model is by far the most practical way to develop sidechains tech. We get half of the problem solved for free, and we can leverage this solved half to make dealing with the unsolved half much easier. For these asymmetric sidechains, nothing is lost by this requirement.