Link to latest code -- also shorter/better explanations (bitcoin#1666)

* Update to CUSF activation client +shorter +clearer

* remove superfluous images

* link to CUSF client, shorter and clearer BIP text

Author: psztorc

bip-0300.mediawiki

@@ -15,9 +15,9 @@
 
 ==Abstract==
 
-Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind").
+Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
 
-Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners.
+Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).
 
 
 ==Motivation==
@@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
 
 ==Notation and Example==
 
-Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
+We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
 
-Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary").
+Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.
 
 
 {| class="wikitable"
@@ -71,119 +71,88 @@ Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.1
 |}
 
 
-Bip301 makes this specialization-of-labor trustless on layer1. If Mary takes Simon's money, then she must let Simon control the side:block.
+BIP-301 makes this specialization-of-labor trustless on L1. If Mary takes Simon's money, then she must let Simon control the side:block.
 
 
 
 ==Specification==
 
+Each candidate for next side:block is defined by its unique side:blockhash "h*". (Even if the entire rest of the L2 block is identical, different Simons will have different side:coinbases and therefore different h*.)
 
-Bip301 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*".
+BIP-301 consists of two messages: "BMM Accept" and "BMM Request".
 
-So we will discuss:
+# "BMM Accept" -- A coinbase output in L1, which contains h*. Mary can only choose one h* to endorse.
+# "BMM Request" -- A transaction where Simon offers to pay Mary, if (and only if) Mary's L1 block contains Simon's h*.
 
-# h* -- The sidechain's hashMerkleRoot, and why it matters.
-# "BMM Accept" -- How h* enters a main:coinbase. When Mary "accepts" a BMM Request, Mary is ''endorsing a side:block''.
-# "BMM Request" -- Simon offering money to Mary, if (and only if) she will Endorse a specific h*. When Simon broadcasts a BMM Request, Simon is ''attempting a side:block''.
-
-
-=== h* ===
-
-h* ("h star") is the sidechain's Merkle Root hash.
-
-In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important.
-
-Note: in Bip301 sidechains, "headers" and "block hashes" do not have significant consensus meaning and are in the design mainly to help with IBD. (In the mainchain, in contrast, headers and block hashes determine the difficulty adjustments and cumulative PoW.)
-
-<img src="bip-0301/sidechain-headers.png?raw=true" align="middle"></img>
-
-
-Above: h* is located in the main:coinbase. h* contains all side:txns, including the side:coinbase. The side:coinbase contains many "header-like" fields, such as the hash of the previous side:block.
-
-Mary controls the main:coinbase, so she may select any h*. Her selection will determine which side:block is "found".
+As a miner, Mary controls the main:coinbase, so she may select any h*. Her selection determines which side:block is "found" -- and which associated BMM Request she can collect.
 
 
 === BMM Accept  ===
 
-To "Accept" the BMM proposal (and to accept Simon's money), Mary must endorse Simon's block.
+To "Accept" a BMM proposal (endorsing Simon's side:block, and allowing Mary to accept Simon's money later in the block), Mary places an OP_RETURN output into the main:coinbase as follows:
 
 <pre>
-For each side:block Mary wishes to endorse, Mary places the following into a main:coinbase OP_RETURN:
     1-byte - OP_RETURN (0x6a)
     4-bytes - Message header (0xD1617368)
+    1-byte - Sidechain number (0-255)
     32-bytes - h* (obtained from Simon)
 </pre>
 
-[https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3530-L3572 Code details here].
+[https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L252-L264 Code details here].
 
 If these OP_RETURN outputs are not present, then no Requests were accepted. (And, Mary would get no money from Requests.)
 
-It is possible for Mary and Simon to be the same person.They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.
+It is possible for Mary and Simon to be the same person. They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.
 
 When Simon and Mary are different people, Simon will need to use BMM Requests.
 
 === BMM Request ===
 
-Simon will use BMM Requests to buy the right to find a sidechain block, from Mary.
+Simon will use BMM Requests to buy the "right" to find a sidechain block, from Mary.
+
+For each side:block that Simon wants to attempt, he broadcasts a txn containing the following as an OP_RETURN:
 
 <pre>
-For each side:block that Simon wants to attempt, he broadcasts a txn containing the following:
-        3-bytes - Message header (0x00bf00)
-        32-bytes  - h* (side:MerkleRoot)
-        1-byte  - nSidechain (sidechain ID number)
-        4-bytes - prevMainHeaderBytes (the last four bytes of the previous main:block)
+    1-byte - OP_RETURN (0x6a)
+    3-bytes - Message header (0x00bf00)
+    1-byte - Sidechain number (0-255)
+    32-bytes  - h* (obtained from L2 node)
+    32-bytes  - prevMainBlock (the blockhash of the previous main:block)
 </pre>
 
-We make use of the [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/primitives/transaction.h#L224-L331 extended serialization format]. (SegWit used ESF to position scriptWitness data within txns; we use it here to position the five fields above.)
-
-
-The Message header identifies this txn as a BMM transaction. h* is chosen by Simon to correspond to his side:block. nSidechain is the number assigned to the sidechain when it was created. preSideBlockRef allows Simon to build on any preexisting side:block (allowing him to bypass one or more invalid blocks, details below). prevMainHeaderBytes are the last four bytes of the previous main:block (details below).
+h* is chosen by Simon to correspond to the side:block he wants to mine on the alt-chain. nSidechain is the number assigned to the sidechain/alt-chain when it was created.
 
 This txn is invalid if it fails any of the following checks:
 
 # Each "BMM Request", must match one corresponding "BMM Accept" (previous section).
-# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM 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 valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
+# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must single out one BMM_Request_4 to include in this L1 block.
+# The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.
 
 
-Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can become a bona fide transaction, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most.
+Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one that pays her the most.
 
 This BIP allows BMM Requests to take place over Lightning. One method is [https://www.drivechain.info/media/bmm-note/bmm-lightning/ here]. (BMM Accepts cannot be over LN, since they reside in main:coinbase txns.)
 
-==Backward compatibility==
-
-As a soft fork, older software will continue to operate without modification. To enforce BMM trustlessly, nodes must watch "pairs" of transactions, and subject them to extra rules. Non-upgraded nodes will notice that this activity is present in the blockchain, but they will not understand any of it.
 
-Much like P2SH or a new OP Code, these old users can never 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 BTC here, all happen to be miners. So there is less reason than ever to expect compatibility problems.)
+==Backward compatibility==
 
-As with all previous soft forks, non-upgraded users are indirectly affected, in that they are no longer performing full validation.
+This soft fork can be deployed without modifying Bitcoin Core at all (ie, via [https://bip300cusf.com/ CUSF]).
 
 
 ==Deployment==
 
-This BIP will be deployed via UASF-style block height activation. Block height TBD.
-
-
-==Reference Implementation==
-
-See: https://github.com/drivechain-project/mainchain
-
-Also, for interest, see an example sidechain here: https://github.com/drivechain-project/sidechains/tree/testchain
+This BIP deploys when/if >51% hashrate runs [https://github.com/LayerTwo-Labs/bip300301_enforcer/ the enforcer client].
 
+Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.
 
-==References==
-
-* http://www.drivechain.info/literature/index.html
-* http://www.truthcoin.info/blog/blind-merged-mining/
-* http://www.truthcoin.info/images/bmm-outline.txt
 
+==Reference Implementation==
 
-==Thanks==
+The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
 
-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.
+Also, several example L2s using BIP-301 are [https://releases.drivechain.info/ here].
 
 
 ==Copyright==
 
 This BIP is licensed under the BSD 2-clause license.
-