BIP 301: Blind Merged Mining (Consensus layer) #643
Conversation
|
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
|
There was a problem hiding this 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:
- Requires changes to the Bitcoin protocol.
- Limited to merely 256 sidechains.
- Requires conveying the prevblock for no apparent reason.
- Requires softforks for sidechains.
- Includes information on sequence of sidechains in the mainchain for no apparent reason. (Skip count is especially redundant since the prev is already explicit)
- No merkle tree for sidechain data!
- Requires full nodes maintain a new database.
- Requires finding a Bitcoin block for any merged chains.
bip-blind-merged-mining.md
Outdated
|
|
||
| Specifically, per side:block per side:chain, we track the following 35 bytes of information: | ||
|
|
||
| 1-byte - ChainIndex (known as "Account Number" in hashrate-escrows.md , or as "Sidechain Number") |
There was a problem hiding this comment.
Now, it is here, in the first BIP: https://github.com/bitcoin/bips/pull/642/files#diff-faa5d00974be8fe9f13c7d7fec81b7ee
bip-blind-merged-mining.md
Outdated
| Abstract | ||
| ========== | ||
|
|
||
| Blind Merged Mining (BMM) is a way of mining special extension blocks, ie "sidechains". It produces strong guarantees that the block is valid, for *any* arbitrary set of rules; and yet it does so without requiring miners to actually do any validation on the block whatsoever. |
There was a problem hiding this comment.
Extension blocks and sidechains are two different things.
There was a problem hiding this comment.
They are indeed. I feel that an asymmetric sidechain is the same as an optional extension block. I will clarify it.
bip-blind-merged-mining.md
Outdated
|
|
||
| Since the hashes themselves are already ordered by the mainchain, tracing the blockchain's path by index (prevBlockRef) will be the same as tracing it by identifying a list of hashes. In other words, the ordering given via each side:block's "prevBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ... if "prevSideHeaderHash is defined to be the sidechain's equivalent of the mainchain's "prevBlockHash". It will be possible to freely convert from one to the other. See M8 to learn more about how these hashes are requested by sidechain block creators to be included in the mainchain. | ||
|
|
||
| Now that we know what our critical data is, and how it is made, how is this data broadcast and stored? |
There was a problem hiding this comment.
It's not made clear why this data is considered critical... It certainly doesn't seem like it should be.
There was a problem hiding this comment.
I have clarified this part by adding: " This data is "critical" in the sense that it is the minimum amount of data required to define a sidechain. "
bip-blind-merged-mining.md
Outdated
| 4-byte - Message header (0xD3407053) | ||
| (n*(32+5))-byte - A sequence of bytes, of the three Mini-Header items (h*, prevBlockRef, ChainIndex). | ||
|
|
||
| ( We assume that 5 bytes are used for the Critical Data bytes (non h* parts of the Sidechain Mini-Header). For 256 sidechains, a total of 9,478 bytes [1+1+4+256\*(32+5)] are required, conveniently just below the 10 KB scriptPubKey size limit.) |
There was a problem hiding this comment.
Why? This is useless data to the main chain.
There was a problem hiding this comment.
The mainchain needs this data in order to validate the two styles of "M8" transaction.
bip-blind-merged-mining.md
Outdated
|
|
||
| This section introduces a new type of transaction, which allows sidechain block creators to request, and pay for, a critical hash to be included in a specific block by mainchain miners. See [the Blind Merged Mining spec](http://www.truthcoin.info/blog/blind-merged-mining/). This txn allows miners to "sell" the act of mining a sidechain block. By taking advantage of this option, miners earn tx fees for mining sidechains...truly "for free". They do not even need to run sidechain nodes, and the tx-fees they earn are in mainchain BTC. As a result, sidechains affect all miners equally and do not affect the mining ecosystem. | ||
|
|
||
| M8 will ultimately come in two versions. The second version will be specialized for use in the Lightning Network and must use the full 32-byte prevBlockHash (ironically, this larger transaction is cheaper for the Bitcoin network to process, as it is completely off-chain). The first version of M8, in contrast, cannot be used inside the Lightning Network, but is slightly more space-efficient (using the 2 prevBlockRef bytes to maintain chain order). It is important to make both options available to the user, because some side:nodes may be unwilling or unable to open a payment channels with each main:miner. However, in the long run we expect the lightning version to be preferred. |
There was a problem hiding this comment.
Lightning doesn't require you to have a channel with the recipient...
There was a problem hiding this comment.
Yes, I have edited this part to instead read "LN connection". Although, it does not change the point I was trying to make.
bip-blind-merged-mining.md
Outdated
|
|
||
| Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: | ||
|
|
||
| 1. Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) |
There was a problem hiding this comment.
They can take a merged chain header from someone else risk-free.
There was a problem hiding this comment.
Is there not a risk that they will get a merged chain header that is ultimately invalid (as I say above)? If so than it is not risk free.
bip-blind-merged-mining.md
Outdated
| Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: | ||
|
|
||
| 1. Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) | ||
| 2. Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity). |
There was a problem hiding this comment.
They can accept payment in any way they like... nothing stops them from being paid in bitcoins to include the mentioned merge block header.
There was a problem hiding this comment.
The goal here is to make it require zero trust.
The issue is not being paid in BTC (as they will also be paid "in BTC" if they mine a namecoin sidechain [instead of namecoin-altcoin]). Instead, the issue is being paid on the mainchain.
this is what I originally intended, but I forked this branch at the wrong time
CS indicated via tweet that he felt he did not contribute enough to be a co-author
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!!
Yes
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. |
clarifications + backward compatibility
|
I think I am now up to date on Luke's requested changes and clarifications. |
This has been right in the code, but I kept forgetting to update the BIP.
bip-blind-merged-mining.mediawiki
Outdated
| Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: | ||
|
|
||
| # Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) | ||
| # Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity). |
There was a problem hiding this comment.
I'm not sure these are drawbacks. By eliminating them, you essentially turn all sidechain hashrate into a kind of decentralised Nicehash service. This can be catastrophic, since it essentially sells control to the highest bidder, which can easily be an attacker.
There was a problem hiding this comment.
I'm not sure these are drawbacks.
The first is, I think. Some miners complained about Namecoin's buggy software, and refused to use it -- leading to suboptimal NMC hashrate, and disproportionate 2x-sha256 rewards (which some SC reviewers are strongly against). Also, if/when namecoin software crashed, it (very temporarily) took down the Bitcoin hashing network with it.
The second is really just a convenience. I suppose it is better for miners to "dogfood" (in a sense) their coinbases (they will be more loyal to Namecoin if they are paid in NMC). But in the sidechains case, they are being paid with BTC, and their ASICs have been designed mine BTC.
sells control to the highest bidder
This does give control over block ordering to the highest bidder. I am truly not sure what will happen as a result.
But first of all we are already in a world where control goes to the highest bidder -- today, they must instead bid using illiquid currencies -- ASIC equipment and electrical power. But if they win then they will have "control" (in the same limited sense that miners have control over block ordering today).
But, hashes/second has a time component, whereas the bidding in blind merged mining does not.
On the other hand, when Bitcoin has no block subsidy, an attacker can broadcast a string of "attack transactions" that pay extremely large fees, and thus induce miners to reorg the chain. It really comes down to the wealth generated by the chain, I think (whether it is a main- or side- chain).
bip-blind-merged-mining.mediawiki
Outdated
|
|
||
| === Sidechain Critical Data ("Sidechain Mini-Header") === | ||
|
|
||
| Specifically, per side:block per side:chain, we track the following 35 bytes of information: |
There was a problem hiding this comment.
This is a huge scalability regression for sidechains, which currently can be increased in number infinitely without adding more than a fixed 32 bytes to Bitcoin's blocks.
There was a problem hiding this comment.
Hmm, yes I think it is.
But it is intended to respond to the allegation that, in practice, miners would need to run a sidechain node. In that case, the scalability regression would be several orders of magnitude greater. Instead of 32 bytes in your example, it would be infinite bytes.
There was a problem hiding this comment.
The scalability regression affects not just miners, but all full nodes.
There was a problem hiding this comment.
That is correct. It is part of the tradeoff required for trustless BMM.
One could still use the technique of BMM, without any code changes to Bitcoin. But it would involve some trust -- likely, side:nodes would have to open (and fund) an account with pools. Side:nodes would then request that the pool find certain side:blocks ("blindly") and the pool would then deduct some value (side:txn_fees - epsilon) from the node's account.
bip-blind-merged-mining.mediawiki
Outdated
|
|
||
| ===== Creation ===== | ||
|
|
||
| By the time Blind Merged Mining can take place, the ChainIndex is globally known (it is the "Account Number" in D1 [see previous BIP], and "nSidechain" in the code). Each sidechain, when activated by soft fork, will take one of the 0-255 available indexes. |
There was a problem hiding this comment.
Why would there only be 256 sidechains?
There was a problem hiding this comment.
We only allocate one byte to identifying a sidechain.
But there can be sidechains-of-sidechains, so in practice there is no real limit.
bip-blind-merged-mining.mediawiki
Outdated
|
|
||
| <img src="bip-blind-merged-mining/bmm-dots-examples.png?raw=true" align="middle"></img> | ||
|
|
||
| Since the hashes themselves are already ordered by the mainchain, tracing the blockchain's path by index (prevBlockRef) will be the same as tracing it by identifying a list of hashes. In other words, the ordering given via each side:block's "prevBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ... if "prevSideHeaderHash is defined to be the sidechain's equivalent of the mainchain's "prevBlockHash". It will be possible to freely convert from one to the other. See M8 to learn more about how these hashes are requested by sidechain block creators to be included in the mainchain. |
There was a problem hiding this comment.
What about side:blocks that do not meet the difficulty of a valid Bitcoin block (but still remain a valid sidechain block)?
There was a problem hiding this comment.
Such a block would not be a found sidechain block. It would just be a candidate for the next block (perhaps), or else it would be some arbitrary collection of mempool data.
In BMM, a sidechain header meets its difficulty requirement if and only if the header is included in a mainchain Bitcoin block. That is the only way it can meet its "difficulty" requirement. This is a difference from regular merged mining.
bip-blind-merged-mining.mediawiki
Outdated
|
|
||
| ==== M7 -- "Blind-Mine the Sidechain(s)" ==== | ||
|
|
||
| Thus, (for n sidechains) we have a coinbase output with multiple OP_RETURNs (we've changed the tx-standardness policy to allow multiple OP_RETURNs): |
There was a problem hiding this comment.
There is no tx-standardness policy for coinbases (it is a self-contradicting concept)... Nor are such matters of policy subject to BIPs - they are entirely up to implementations and/or individual node operators.
There was a problem hiding this comment.
That may be so, but in practice many people have pointed out to me that I am "not allowed" to use multiple OP Returns. So it definitely interests some readers.
And we did in fact change the standardness policy.
Should we ensure that we have only changed the policy for coinbase txns only?
There was a problem hiding this comment.
Policy is about off-chain transaction acceptance. There is no policy for on-chain blocks - just consensus rules.
There was a problem hiding this comment.
Ah, I see what you are saying.
I will try to find a way to clarify the sentence.
bip-blind-merged-mining.mediawiki
Outdated
|
|
||
| <pre> | ||
|
|
||
| BIP: ???? |
luke-jr
changed the title
|
Can we get this renamed and merged? |
|
@luke-jr is it still ready to merge? |
|
Hey all, would love to see more progress on this, when merge? |
|
@psztorc The file needs to be named bip-0301.mediawiki (and README updated) |
|
Ok it's been renamed @luke-jr |
bip-0301.mediawiki
Outdated
| @@ -0,0 +1,234 @@ | |||
| <pre> | |||
|
|
|||
There was a problem hiding this comment.
Please check the preamble is formatted correctly. (There shouldn't be blank lines here.)
README will also need to be updated.
|
Ok, spaces deleted and README updated |
This is a draft of a bip for blind merged mining, the second of two drivechain bips.