Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIP 301: Blind Merged Mining (Consensus layer) #643

Merged
merged 32 commits into from Jul 26, 2019
Merged
Changes from all commits
Commits
Show all changes
32 commits
Select commit Hold shift + click to select a range
0a1d358
Create images.txt
psztorc Feb 4, 2018
db86b89
Add files via upload
psztorc Feb 4, 2018
2580d65
Add files via upload
psztorc Feb 4, 2018
da2e574
Add files via upload
psztorc Feb 4, 2018
1af547c
Delete bip-hashrate-escrows.md
psztorc Feb 4, 2018
4bea2ef
one bip at a time
psztorc Feb 4, 2018
39a8bec
Delete images.txt
psztorc Feb 4, 2018
3246096
Delete two-groups.png
psztorc Feb 4, 2018
8a8c625
re-reverse the bips
psztorc Feb 10, 2018
99f5530
mediawiki format
psztorc Feb 10, 2018
9207df7
fix mediawiki formatting
psztorc Feb 10, 2018
486505b
typos
psztorc Feb 10, 2018
68918ad
resync
psztorc Feb 10, 2018
70f0ed6
switch to mediawiki format
psztorc Feb 10, 2018
5418516
typos
psztorc Feb 10, 2018
17db872
move Chris
psztorc Feb 10, 2018
cebe06b
Merge pull request #1 from psztorc/blind-merged-mining
psztorc Feb 10, 2018
2a98136
clarifications + backward compatibility
psztorc Feb 10, 2018
5353f9e
Merge pull request #2 from psztorc/blind-merged-mining
psztorc Feb 10, 2018
485b131
m7 op return update
psztorc Apr 24, 2018
c90088e
improved image, with examples
psztorc Apr 4, 2019
bbcab02
number, shorten, clarify, link to working code
psztorc Apr 4, 2019
2d7093b
spellcheck
psztorc Apr 5, 2019
d69e368
typo
psztorc Apr 17, 2019
329df0b
Update dates/links to merge
psztorc Jul 23, 2019
6ca33dc
Rename bip-blind-merged-mining.mediawiki to bip-0301.mediawiki
psztorc Jul 23, 2019
1ff5d5d
rename folder
psztorc Jul 23, 2019
42e9685
move images
psztorc Jul 23, 2019
69670c9
cleanup 1
psztorc Jul 23, 2019
4cd4e53
cleanup 2
psztorc Jul 23, 2019
db117ef
fix spacing
psztorc Jul 26, 2019
542c66e
Add 301 Blind Merged Mining
psztorc Jul 26, 2019
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.

Always

Just for now

@@ -805,6 +805,13 @@ Those proposing changes should consider that ultimately consent may rest with th
| Sean Bowe, Daira Hopwood
| Standard
| Draft
|-
| [[bip-0301.mediawiki|301]]
| Consensus (soft fork)
| Blind Merged Mining (Consensus layer)
| Paul Sztorc, CryptAxe
| Standard
| Draft
|}

<!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! -->
@@ -0,0 +1,226 @@
<pre>
BIP: 301
Layer: Consensus (soft fork)
Title: Blind Merged Mining (Consensus layer)
Author: Paul Sztorc <truthcoin@gmail.com>
CryptAxe <cryptaxe@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-301
Status: Draft
Type: Standards Track
Created: 2019-07-23
License: BSD-2-Clause
</pre>

==Abstract==


Blind Merged Mining (BMM) is a way of mining optional extension blocks (ie, "asymmetric sidechains"). BMM produces weak 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.

BMM actually is a process that spans two or more chains. Here we focus on the modifications to mainchain Bitcoin. For an explanation of the "whole picture", please see [http://www.truthcoin.info/blog/blind-merged-mining/ this post].

Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block.


==Motivation==

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).
BMM addresses both shortcomings.


==Specification==

Note: This document uses the notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain counterpart. We also use "Simon" to refer to a Sidechain Full Node, and "Mary" to refer to a mainchain miner.


=== BMM Request ===

To buy the right to find a sidechain block, users broadcast BMM Requests.

Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message.

Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how SegWit handles witness data (the witness stack)).

==== Immediate Expiration ("Fill-or-Kill") ====

We would like to make special guarantees to the counterparties of this transaction. Specifically, instead of Simon making a "payment" to Mary, we prefer that Simon give Mary an "offer" (which she can either accept or decline).

Crucially, we want Simon to safely make many offers to several different Mary's, in realtime (ie, quickly and off-chain). However, we ultimately want only one offer to be accepted, at most. In other words, we want Simon's offers to *immediately expire*. If only one offer can become a bona fide transaction, then Simon will feel comfortable making multiple offers all day long. Because all of the Simons are making many offers, the Marys collectively gain access to a large set of offers to choose from.

==== OnChain BMM Request ====

OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation.

===== Structure =====

The following data is required:

<pre>
32-bytes - h* sideHeaderHash
?~?-bytes - critical data extended serialization
3-bytes - 0x00bf00 identifying bytes
1-byte - nSidechain
2-bytes - prevSideBlockRef
4-bytes - prevMainHeaderBytes
</pre>

sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally.

prevBlockRef, is a little more complicated (next section).

To qualify for inclusion in a block, BMM requests are subject to the following requirements:

# Requests must match a corresponding "BMM Accept" (see last section of BIP).
# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include.
# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
===== prevBlockRef =====

prevBlockRef is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain blocks). If a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N; in the block after that it will be back to zero.

<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img>

Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other.

===== Extended Serialization =====

To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).

<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img>

Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here].

These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned.

Interestingly, these payments will *always* be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks).

==== Lightning BMM Request ====

Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today.

LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data:

<pre>
4-bytes - Message header (0xD0520C6E)
1-byte - sidechain number
32-bytes - h* side:block hash
32-bytes - prevSideBlockHash
</pre>

Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything.

Therefore, Simon will need to ensure that he '''gives each Mary a different h\*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*).

With a unique h\* per Mary (or, more precisely, per channel), and at most 1 h\* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time.

That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary.

We start with (I):

<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
13 ; to Simon if TimeLock=over; OR to Mary if SimonSig
40 ; to Mary
Mary's version [signed by Simon]
40 ; to me if TimeLock=over; OR to Simon if MarySig
13 ; to Simon
</pre>


And both parties move, from there to (II):

<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
40 ; to Mary
7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over
Mary's version [signed by Simon]
40 ; to Mary if TimeLock=over; OR to Simon if MarySig
6 ; to Simon
7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over
</pre>


From here, if the h\* side:block in question is BMMed, they can proceed to (III):

<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
47 ; to Mary
Mary's version [signed by Simon]
47 ; to me if TimeLock=over; OR to Simon if MarySig
6 ; to Simon
</pre>

If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it.

If the h\* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h\*, trying again with new side:block in the next main:block).

Now that we have described Requests, we can describe how they are accepted.

=== BMM Accept ===

For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)

The following data is required in the "accept" OP_RETURN output:
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-bytes - Message header (0xD3407053)
32-bytes - h*
~5-bytes - BMM identifier bytes


[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code].

If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.)


==Backward compatibility==

As a soft fork, older software will continue to operate without modification. As stated above, BMM asks nodes to track a set of ordered hashes, and to allow miners to "sell" the act of finding a sidechain block. Non-upgraded nodes will notice that this activity (specifically: data in coinbases, and new txns that have OP Returns and interesting message headers) is now taking place, but they will not understand any of it. Much like P2SH or a new OP Code, these old users will not be directly affected by the fork, as they will have no expectations of receiving payments of this kind.

(As a matter of fact, the only people receiving money here all happen to be miners. So there is less reason than ever to expect compatibility problems.)


==Deployment==

This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and using bit 4.

<pre>
// Deployment of Drivechains (BIPX, BIPY)
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021.
</pre>


==Reference Implementation==

See: https://github.com/DriveNetTESTDRIVE/DriveNet

Also, for interest, see an example sidechain here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM


==References==

* http://www.drivechain.info/literature/index.html
* http://www.truthcoin.info/blog/blind-merged-mining/
* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014789.html
* http://www.truthcoin.info/images/bmm-outline.txt

==Thanks==

Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber.


==Copyright==

This BIP is licensed under the BSD 2-clause license.
Binary file not shown.
@@ -0,0 +1 @@
Images used as reference in the documentation.
Binary file not shown.