resync

6 files changed, 329 insertions, 483 deletions

diff --git a/bip-blind-merged-mining.md b/bip-blind-merged-mining.md
new file mode 100644
index 0000000..f203e40
--- /dev/null
+++ b/bip-blind-merged-mining.md
@@ -0,0 +1,329 @@
+    Drivechain Documentation -- Blind Merged Mining BIP
+    Paul Sztorc
+    November 17, 2017
+    Document 3 of 3
+    v4.1
+
+
+Header
+=======
+
+    BIP: ????
+    Layer: Consensus (soft fork)
+    Title: Blind Merged Mining (Consensus layer)
+    Author: Paul Sztorc <truthcoin@gmail.com>
+            CryptAxe <cryptaxe@gmail.com>
+            Chris Stewart <chris@suredbits.com>
+    Comments-Summary: No comments yet.
+    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???????
+    Status: Draft
+    Type: Standards Track
+    Created: 2017-10-24
+    License: BSD-2-Clause
+
+
+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.
+
+BMM actually is a process that spans two or more chains. For an explanation of the "whole picture", please see [this post](http://www.truthcoin.info/blog/blind-merged-mining/). Here we focus on the modifications to mainchain Bitcoin.
+
+To support BMM, the mainchain is asked to accomplish two goals:
+1. Track a set of ordered hashes (the merged-mining).
+2. Allow miners to "sell" the act of finding a sidechain block (through the use of a new extended serialization transaction type).
+
+These goals are accomplished by forcing nodes to validate two new messages (M7, M8), and track data in one new database (D3).
+
+
+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:
+
+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).
+
+Blind Merged-Mining (BMM) attempts to address those 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.
+
+As stated above, we have two goals: [1] create and monitor an alt-chain (defined only by a deterministic list of hashes), and [2] allow miners to "sell" the act of finding a sidechain block (through the use of a new extended serialization transaction type).
+
+### Sidechain Critical Data ("Sidechain Mini-Header")
+
+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")
+    32-bytes - sideHeaderHash (also known as "h*" / hashCritical, the hash of the sidechain block)
+    2-bytes  - prevBlockRef (an index which points to this side:block's parent side:block)
+
+The **ChainIndex** indicates which sidechain this critical data is relevant to. As we may eventually have more than one sidechain, this serves as an identifier similar to the Bitcoin network's magic bytes (0xF9BEB4D9). Drivechains however only need to use 1 byte for the identifier (there is a hard limit of 256 sidechains identified as 0-255). The **sideHeaderHash** is the hash of a side:block which will receive PoW via BMM. It serves a similar function to Bitcoin's "hashMerkleRoot", in that it contains the data for its blockchain. The **prevBlockRef** forms the set of headers into a blockchain structure by making each headers refer to one parent header. It is most similar to Bitcoin's hashPrevBlock.
+
+Where does this data come from, and how does it get around?
+
+#### Creating / Broadcasting This Data
+
+##### 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.
+
+The other two items, sideHeaderHash and prevBlockRef, are created by sidechain nodes. sideHeaderHash is quite straightforward -- side:nodes build side:blocks, and take the hash of these.
+
+The final item, prevBlockRef, is a little more complicated. It 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. In practice, this value will usually be zero. It will only be a value other than zero, in cases where invalid sidechain blocks have been mined, or when a side:node intentionally wants to orphan some side: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).
+
+![dots-image](/bip-blind-merged-mining/bmm-dots-examples.png?raw=true)
+
+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?
+
+##### Broadcast
+
+Mainchain nodes are going to need this data later, so it must be easy to find. We will put it into the coinbase via OP RETURN.
+
+#### M7 -- "Blind-Mine the Sidechain(s)"
+
+Thus, (for n sidechains) we have a coinbase output with:
+
+    1-byte - OP_RETURN (0x6a)
+    1-byte - Push the following (4+(n*35)) bytes (0x??)
+    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.)
+
+This data is parsed by laying it in sequential 37-byte chunks (any remaining data --ie, some final chunk that is less than 37 bytes in length-- has no consensus meaning). 
+
+Each 37-byte chunk is then parsed to obtain the data outlined above (in "Description"). If two 35-byte chunks being with the same "Sidechain number" (ie, if the two chunks have the same first byte), then only the first chunk has consensus meaning.
+
+We are left with, at most, one (h*, prevBlockRef) pair per sidechain per block. This data is added directly to D3, a new database.
+
+#### D3 -- "RecentSidechains_DB"
+
+To suit our purposes, the mainchain full nodes will need to keep track of the most recent 8000 (h\*, prevBlockRef) pairs.
+
+( This 8,000 figure is a tradeoff between decentralization (costs of running the main:node) and sidechain security -- it requires attackers to merged-mine 8,000 invalid blocks consecutively, in order to cause the sidechain to fail. The mainchain burden is minimal, so this figure might be raised to 12,000 or higher. )
+
+Therefore, D3 would look something like this:
+
+
+           BlockHeight  CB_Index    SC_1   Blks_Atop_1   SC 2   Blks_Atop_2   SC 3   Blks_Atop_3
+            ---------    ------    ------   ---------   ------   ---------   ------   ---------
+       1.    401,005        2      (h*, 0)     7985     (h*, 0)        1     (h*, 0)        0
+       2.    401,006        4      (h*, 0)     7984     (h*, 0)        0     (h*, 1)     7801
+       3.    401,007        2      (h*, 0)     7983     (h*, 5)     2027     (h*, 0)        0
+       4.    401,008        2      (h*, 0)     7982     (h*, 0)     2028     (h*, 1)     7800
+      ...     ...                                                                  )
+    7999.    409,003        3      (h*, 0)        1     (h*, 0)        0     (h*, 0)        1
+    8000.    409,004        2      (h*, 0)        0     (h*, 1)        0     (h*, 0)        0
+
+
+When new sidechains (or "hashrate escrows") are soft-forked into existence, a new column is added to D3 (to contain any BMMing that might be done on it).
+
+For each sidechain we also track the field "Blocks Atop". This is the number of side:blocks that are "on top" of the specified side:block. These might be regarded as "side:confirmations" (pseudo-confirmations that are specific to each sidechain).
+
+D3 also contains a column (not shown) for each sidechain containing "prevSideBlockHash". This value is is either derived from prevBlockRef; or else it is given explicitly (in which case it is the converse: prevBlockRef is derived from prevSideBlockHash).
+
+
+#### Coinbase Cache
+
+As mentioned above, M7s cause data to be added to D3. Recent D3 data is tracked by all mainchain nodes for a period of time.
+
+To efficiently keep track of the above data, without having to constantly load and process entire blocks from disk, we temporarily cache enough coinbases in the chain index to maintain D3.
+
+
+### M8 -- Paying miners to include BMM data in their coinbase outputs
+
+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.
+
+#### Setup
+
+We define **"Mary"** as a mainchain miner, and **"Simon"** as a sidechain node.
+
+The goal is to construct a payment from Simon to Mary, such that:
+
+1. If the critical data conditions are met, **Mary** can claim the outputs of the transaction with finality.
+2. If the critical data conditions are not met, the outputs become immediately available again to **Simon**.
+
+
+#### Goals (this is rather philosophical, and skippable)
+
+##### 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 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.
+
+##### Forward Progress (The Need for a "Ratchet")
+
+The "ratchet" concept is an attempt to harmonize incentives among the main and side chain(s).
+We need to ensure that a sidechain is making "forward progress", without tracking too much about the sidechain such that we burden Bitcoin (see [1] and [2]) all while still allowing the sidechain to reorganize [3].
+
+* [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014789.html
+* [2] http://www.drivechain.info/faq/index.html#what-is-the-difference-between-drivechain-and-extension-blocks
+* [3] http://www.truthcoin.info/blog/blind-merged-mining/#handling-reorganizations
+
+The ratchet system must keep track of sidechain "mini-headers" (see Sidechain Critical Data ("Sidechain Mini-Header")) and count the "blocks atop" maturity of the related side:blocks.
+
+Simon's offer to Mary to include a critical hash in exchange for payment must be *atomic*. The "ratchet" concept helps to construct a very tight connection between two things:
+
+1. The sidechain-block-generator "Simon" paying himself the side:block's side:tx-fees (which he receives in 100 sidechain blocks (blocks atop) hence).
+2. "Simon" making a mainchain main:btc payment to a mainchain miner "Mary".
+
+Either both of the two should succeed, or else both should jointly fail.
+
+However, absent our intervention, there are cases in which [2, the payment to Mary] succeeds but [1, side:tx-fees] fails. One such case is when a side:block contains unusually high side:tx-fees. Here, there will be many requests to include a critical hash in exchange for payment submitted to Mary, but only one can be included in each main:block per sidechain. Without an incentive to make "forward progress", Mary is likely to include one of the highest paying requests in the next main:block (and the main:block after that, and so on). Mary will "blindly" include high-paying requests for *older* blocks, unless something prevents her from doing so.
+
+To address these potential issues, we utilize the concept of "Blocks_Atop" (the "side:confirmations") that we mentioned earlier. As previously mentioned, Mary will not be able to spend Simon's M8 payment until satisfying the critical data requirements as well as the blocks atop (side:confirmations) requirement.
+
+
+#### M8 -- The two forms of M8 transactions
+
+As previously mentioned, M8 can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see above). 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. For the non Lightning version, we have created a new extended serialization transaction type (very similar to how segwit handles witness data (the witness stack)).
+
+##### M8_V1 - No Lightning Network
+
+M8_V1 does not require the Lightning network but does have new requirements for validation.
+
+A M8_V1 TxOut is expected to contain:
+
+    1-byte - OP_RETURN (0x6a)
+    1-byte - Push the following 36 bytes (0x24)
+    4-byte - Message header (0xD1617368)
+    32-bytes  - h* side:block hash
+    5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
+    
+
+In the first version of M8, we need to introduce the concept of Immediate Expiration (see above). In other words, we need a way for Simon to construct many payments to multiple Marys, such that only one of these is ever included; and only then if Simon's txn is expected to coincide with the finding of Simon's side:block.
+
+We do this by imposing validity-rules on the txn itself:
+
+1. The txn's content, when examined, must match part of the main:block's content. Specifically, the (ChainIndex, h\*) pair of the txn, must match one of the (ChainIndex, h\*) pairs in the M7 of this main:block.
+2. Only one payment per sidechain per main:block is valid. In other words, if 400 people all try to bm-mine the sidechain with ChainIndex==4, then not only is it the case that only one side_4:block can be found, but it is also the case that only the corresponding M8 txn can be included (out of all of the 400 M8s which are for ChainIndex==4).
+3. Simon's txns must only be valid for the current block; afterward, they immediately expire. This is because Simon's intended prevBlockRef & side:block contents will most likely change from one main:block to the next.
+
+To impose new requirements on the transaction level (not the block level nor the TxOutput level), we borrow the "flag" trick from SegWit style transactions. If the flag is present, the transaction is examined for extra data, and if this data does not pass certain requirements, the transaction is invalid. With SegWit, this extra data is the signatures, and the extra requirements are the signatures' locations and validity. In the BMM-transactions, the extra data is the (ChainIndex, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).
+
+To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. If the flag is set to 2 (0010), the transaction contains Critical Data and requires that our new validation rules be met in order for the txn to be valid in a block. 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 (ChainIndex, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above). Note The main:blocknumber does not take up any additional space compared to a normal txn, as we reuse the locktime field for our purposes.
+
+
+
+
+![extra-data-image](/bip-blind-merged-mining/witness-vs-critical.png?raw=true)
+
+This txn structure conserves main:blockspace, because it is the easiest way to refer to a previous sidechain block in 4 bytes, (prevBlockRef + FoK_nLockTime). Instead, we would need to use at least 32 bytes (prevSideBlockHash).
+
+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. To be clear, when the transaction is received we are able to evaluate its validity, and do not need to rescan these transactions again.
+
+Interestingly, these payments (M8) will *always* be directed to miners from non-miners. Therefore, non-mining 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 trades (in contrast, regular Bitcoin txns remind me more of paper checks).
+
+##### M8_V2 With Lightning
+
+M8_V2 requires having a LN-channel open with a miner. This may not always be practical (or even possible), especially today.
+
+A M8_V1 TxOut is expected to contain:
+
+    1-byte - OP_RETURN (0x6a)
+    1-byte - Push the following 68 bytes (0x44)
+    4-byte - Message header (0xD0520C6E)
+    32-bytes  - h* side:block hash
+    32-bytes  - prevSideBlockHash
+    5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
+    
+
+Notice that, in M8_V1, Simon could reuse the same h\* all he wanted, because only one M8_V1 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* M8s. So, we will never know what the M8s 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 nonce -- this changes the side:block, and changes its hash (ie, changes h\*).
+
+With a unique h\* per Mary, and at most 1 h\* making it into a block (per sidechain), we can guarantee that only one of the M8_V2's critical data can be committed to in a single main:block. By giving each miner (who Simon has a payment channel open with) a different h*, Simon can figure out which miner followed through with the commit, and know that only one such commit went through. Furthermore, if this Simon's requested critical data is not found in a block, none of the M8_V2 payments will be spendable by the Mary(s), because none of the h\* in question have ever made it into D3 (which is always on-chain) and no blocks atop will be accumulated.
+
+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):
+
+    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
+
+
+And both parties move, from there to "M8_V2" (II):
+
+    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
+
+From here, if the h\* side:block in question is BMMed, they can proceed to (III):
+
+    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
+
+Although, if Simon proceeds immediately, he removes the protection of the 'ratchet'. Ie, Simon 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 the full 100 side:blocks before moving on (ie, 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).
+
+
+
+
+Deployment
+===========
+
+This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and using bit 4.
+
+```
+// Deployment of Drivechains (BIPX, BIPY)
+consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
+consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1515974401; // January 15th, 2018.
+consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1547510401; // January 15th, 2019.
+```
+
+Reference Implementation
+==========================
+
+See: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
+
+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, Ben Goldhaber.
+
+
+Copyright
+==========
+
+This BIP is licensed under the BSD 2-clause license.
diff --git a/bip-blind-merged-mining/bmm-dots-examples.png b/bip-blind-merged-mining/bmm-dots-examples.png
new file mode 100644
index 0000000..70f11f6
--- /dev/null
+++ b/bip-blind-merged-mining/bmm-dots-examples.png
diff --git a/bip-hashrate-escrows/images.txt b/bip-blind-merged-mining/images.txt
index 2fbbf63..2fbbf63 100644
--- a/bip-hashrate-escrows/images.txt
+++ b/bip-blind-merged-mining/images.txt
diff --git a/bip-blind-merged-mining/witness-vs-critical.png b/bip-blind-merged-mining/witness-vs-critical.png
new file mode 100644
index 0000000..1a2458d
--- /dev/null
+++ b/bip-blind-merged-mining/witness-vs-critical.png
diff --git a/bip-hashrate-escrows.mediawiki b/bip-hashrate-escrows.mediawiki
deleted file mode 100644
index 0987bf5..0000000
--- a/bip-hashrate-escrows.mediawiki
+++ /dev/null
@@ -1,483 +0,0 @@
-
-
-<pre>
-    BIP: ????
-    Layer: Consensus (soft fork)
-    Title: Hashrate Escrows (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-???????
-    Status: Draft
-    Type: Standards Track
-    Created: 2017-08-14
-    License: BSD-2-Clause
-    Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
-</pre>
-
-==Abstract==
-
-A "Hashrate Escrow" is a clearer term for the concept of "locked to an SPV Proof", which is itself a restatement of the phrase "within a sidechain" as described in [https://blockstream.com/sidechains.pdf a famous Oct 2014 paper] written partially by some Blockstream co-founders.
-
-A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners. However, the 3rd party does not sign escrow-withdrawal transactions with a private key. Instead, these are "signed" by directing hashpower over them for a period of time.
-
-This project has [http://www.drivechain.info/ a website] which includes [http://www.drivechain.info/faq/index.html a FAQ].
-
-
-==Motivation==
-
-In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [http://www.rsk.co/ Rootstock]) or "virtual chains" within Bitcoin (such as [https://github.com/blockstack/virtualchain proposed by Blockstack] in mid-2016).
-
-Sidechains have many potential benefits, including:
-
-1. Protect Bitcoin from competition from altcoins and spinoffs. Safely allow competing implementations (of *sidechains*).
-2. Protect Bitcoin from hard fork campaigns. (Such campaigns represent an existential threat to Bitcoin, as well as an avenue for developer corruption.)
-3. Help with review, by making it much easier for reviewers to ignore bad ideas.
-4. Provide an avenue for good-but-confusing ideas to prove their value safely.
-
-
-
-==Specification==
-
-==== Components ====
-
-Hashrate Escrows are built of two types of component: [1] new databases, and [2] new message-interpretations.
-
-===== 1. New Databases =====
-
-* D1. "Escrow_DB" -- a database of "accounts" and their attributes.
-* D2. "Withdrawal_DB" -- a database of pending withdrawals from these accounts, and their statuses.
-
-Please note that these structures (D1 and D2) will not literally exist anywhere in the blockchain. Instead they are constructed from messages...these messages, in contrast, *will* exist in the blockchain (with the exception of M4). 
-
-===== 2. New Messages =====
-
-* M1. "Propose New Escrow"
-* M2. "ACK Escrow Proposal"
-* M3. "Propose Withdrawal"
-* M4. (implied) "ACK Withdrawal"
-* M5. "Execute Deposit"   -- a transfer of BTC from-main-to-side
-* M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main
-
-
-==== On the Resource Requirements of New Databases ====
-
-The "new" databases are simply reinterpretations of data that are already contained elsewhere in the blockchain. Specifically, M1 M2 and M3 are all located in the block's coinbase txn, and M5 and M6 might be found in any regular txn. M4 is a special case and does not actually need to be included anywhere, so it is not. If you like, you can imagine that the M4s reside in an optional extension block.
-
-In other words, we just rearrange what is already there. Because of this, even though "new databases" are created and stored in memory, the existing bandwidth and storage limits are respected (although, see "M4" below).
-
-
-
-
-=== Adding Sidechains and Tracking Them (D1, M1, M2) ===
-
-==== D1 -- "Escrow_DB" ====
-
-The table below enumerates the new database fields, their size in bytes, and their purpose. In general, an escrow designer (for example, a sidechain-designer), is free to choose any value for these.
-
-Note: Fields 6 through 9 have been intentionally removed. Previously, this section allowed miners to set and commit to voting/waiting periods. However, I have since standardized the periods: withdrawals expire after 6 months (26298 blocks), and they succeed if they ever achieve an ACK score of 13140 or higher. I have removed the waiting period, because anyone who adopts a policy of ignoring all withdrawals with fewer than 400 ACKs will automatically gain all of the benefits of the waiting period. The justification for this change is that it strongly implies that an attack on any one sidechain is an attack on all of them (in a sense, this change makes the "victimhood" of each sidechain "fungible").
-
-{| class="wikitable"
-! Field No.
-! Label
-! Bytes
-! Type
-! Description / Purpose
-|-
-| 1
-| Escrow Number
-| 1
-| uInt
-| A number assigned to the entire escrow. Used to make it easy to refer to each escrow.
-|-
-| 2
-| Active*
-| 2
-| uInt
-| This counter starts at zero when a new entry is added, and increments as a new entry is supported by "M2". The entry either reaches the max value of 4032 (at which point the counter freezes), or else the entry is removed. This enforces the requirement "a soft fork is required to add a new escrow".
-|-
-| 3
-| Escrow Name/Description
-| 120
-| string
-| A human-readable name and description of the sidechain. More than enough space to hold a 32 byte hash. Helps prevent destructive interference among sidechains (see below).
-|-
-| 4
-| Critical Private Key
-| 32
-| hex
-| This is the Double-SHA256 of the binary release of the reference software. It ties the sidechain to a specific software release, and doubles as a way of signing withdrawals (see below).
-|-
-| 5
-| Critical Address*
-| 32
-| string
-| This is derived by taking f(x) = ImportPrivateKey(HexToBase58Check(x)) of field #3. It is intentionally in the human-readable format {{although it could be 25 bytes of binary}}.
-|-
-| 10
-| "CTIP" -- Part 1 "TxID"*
-| 32
-| hex
-| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the escrow's money is (ie, which member of the UTXO set).
-|-
-| 11
-| "CTIP" -- Part 2 "Index"*
-| 4
-| hex
-| Of the CTIP, this is second element of the pair: the Index. See #10 above.
-|}
-
-\* Denotes a "convenience field", the entry for this field is derived from other fields, or from the blockchain-state itself. The escrow-creator does not need to provide these values in M1 (or anywhere).
-
-Escrow_DB requires 223 bytes [1+120+32+32+2+32+4] for each escrow in the main blockchain. Of these, 70 bytes [2+32+32+4] are merely for convenience. Therefore, a sidechain is defined (see "M1") by 153 bytes of information.
-
-====Notes on D1====
-
-# D1 will always exist.
-# D1 will always have a unique sort (first by "Escrow Number" (field #1), and second by "Active" (field #2)). There is only ever one (escrow number, Active) pair. 
-# D1 is updated according to M1 and M2 (below).
-# If a new entry is added to D1 with an "Escrow Number" that is already in use, then this entry will either eventually be removed (because it was not supported with an M2), or it will eventually overwrite the old entry (if it *was* supported via M2).
-
-
-====Notes on D1====
-
-=====Obligations Placed on Miners=====
-
-Miners have always upgraded their software according to criteria that are known only to them (in other words, "whenever they want").
-
-However, this soft fork imposes two new criteria upon them. First: miners should only upgrade their software, if any modification to the portfolio of sidechains [that are added/removed in the upgrade] can be expected to increase miner wealth. Trivially, this implies that miners should make sure that the upgrade doesn't overwrite (and destroy) an existing sidechain that they like! But, more seriously, it implies that miners should take an interest in what the sidechain is doing to the mainchain and other sidechains (see below).
-
-===== Destructive Sidechain Interference =====
-
-People frequently emphasize that miners should have "as little control" as possible. It is a very safe claim to make, and a very easy sentence to write. Much harder is to determine exactly what this minimum value is, and how to achieve it. Harder still is to untie the knot of who is actually controlling what, in a decentralized, interacting system.
-
-Certainly, miners can not have "zero control" -- for that is the same as to just remove them from the system altogether. Some rules are enforced "on miners by nodes" (such as the infamous blocksize limit); other rules are enforced by nodes but are narrowly-controlled by miners (such as the proof-of-work itself, or the block's timestamp). Thirdly, some rules are enforced by both against each other (such as the rule against including invalid txns or double-spent txns), for mutual benefit.
-
-Some pause should be given, after one considers that the sidechain design goal is literally a piece of software that can do *anything*. Anything includes a great many things, many of which I demonstrate to be undesirable. Bitcoin itself does not allow "anything" -- it allows any person to transact, but, in contrast, it does not permit any person to double-spend. This is because "allowing anyone to do anything" is not viable in a world that contains undesirable interactions (what a libertarian might call "aggression") -- in the case of money, these are theft and counterfeiting.
-
-I have produced a comprehensive quantity of written material [1], presentations [2], etc [3] on exactly what the level of miner-control should be, and why. Specifically, I claim that **miners should be aware of the purpose of the sidechain, and they should reject sidechains which have an unclear purpose or which have a purpose that will lead to decrease in miner-wealth** (where wealth measured explicitly as: the estimated present value of the purchasing power of the blockchain's coinbase txns). I claim that this criterion is necessary because, just Original Bitcoin filters unwanted interactions among different BTC txns, so too much "Sidechain Bitcoin" filter out unwanted interactions among sidechain.
-
-* [1] http://www.truthcoin.info/blog/wise-contracts/
-* [2] https://www.youtube.com/watch?v=xGu0o8HH10U&index=1&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4
-* [3] http://www.drivechain.info/literature/index.html
-
-Call it a "sidechain non-aggression principle", if you want.
-
-To the best of my knowledge, everyone who *has* reviewed this information as found the arguments to be acceptable. It has, also, changed a few minds (from "unacceptable" to "acceptable").
-
-
-===== ISSUE: "Signing" BTC Txns =====
-
-Currently, we use a process which may be suboptimal. It is that we *literally sign* a txn with a globally and publicly known private key. But this is for convenience purposes -- the signature that is produced is not doing anything, and is therefore wasteful. Instead we may use OP_TRUE, but this might interfere with how we detect the sidechain's balance. I'm not sure what the best way is. Someone needs to investigate how to do this -- removing OP_CheckSig, etc. This is a TODO for sure, and an opportunity for someone to help.
-
-
-
-(The following messages were modeled on SegWit -- https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure )
-
-
-
-==== M1 -- "Propose New Sidechain" ====
-
-    1-byte - OP_RETURN (0x6a)
-    1-byte - Push the following 157 bytes (0x9d)
-    4-byte - Commitment header (0x53707243)
-    153-byte - the critical bytes mentioned above (fields #1, #3, and #4, to populate a new D1 entry)
-
-
-==== New Block Validation Rules ====
-
-# If the network detects a properly-formatted M1, it must add an entry to D1, into the very next block, with the following initial values:
-## Field #5 will be calculated as per [https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses version 1 Bitcoin addresses], but with a prefix of "4" instead of "1".
-## Field #9 will be derived from #7 and #8 using math.
-## The initial values of Fields #10, #11, and #12 are set to zero.
-# Only one M1 (of any kind) can be added into a block at a time.
-
-==== Notes on M1 ====
-
-The escrow will "reuse" the same address over and over. But notice that there is no privacy loss due to address reuse, because the address in question does not "belong" to any specific individual. Furthermore, the transactions in question could already be linked by just watching the Hashrate Escrow for deposits ...this, in fact, is exactly what a sidechain must do in order to make main-to-side transfers.
-
-
-==== M2 -- "ACK Sidechain Proposal" ====
-
-    1-byte - OP_RETURN (0x6a)
-    1-byte - Push the following 29 bytes (0x1D)
-    4-byte - Commitment header (0x53616343)
-    25-byte - Commitment hash: RIPMD-160 of Sha256 of a given M1 (above)
-
-==== New Block Validation Rules ====
-
-1. An entry will be removed from D1, unless that block contains an M2 supporting it (this will increment field #2), or the entry has accumulated 4032 M2s. Therefore, each entry needs to have 4032 *consecutive* M2s supporting it, else it will be removed from D1 and must start over. This requires all miners to agree to "soft fork" the sidechain into existence. This makes it easier to curate the list of active sidechains, and prevents destructive interference (see above) among contradictory sidechains.
-2. Once the entry has 4032 M2s, then a miner must make a 0 btc payment to the Critical Address, thus activating the chain. This payment becomes the first "critical (TxID, index) pair" (or "CTIP").
-3. It is possible to "overwrite" a D1 slot -- this destroys the sidechain that is there, and replaces it with a new one. This is defined as requiring 6 months (26298 blocks) of M2s, instead of 4 weeks (4032). This possibility does not change the security assumptions, because we already assume that users have access to "magically true" bandwidth at a rate of 1 bit per ACK-cycle. (This is why the voting cycles should be large, 1 month Waiting, 2+ months Voting).
-
-
-
-=== Adding Withdrawal-Attempts and Tracking Their Success (D2, M3, M4) ===
-
-==== D2 -- "Withdrawal_DB" ====
-
-The table below enumerates the database fields, their size (in bytes), type and purpose.
-
-
-{| class="wikitable"
-! Field No.
-! Label
-! Bytes
-! Type
-! Description / Purpose
-|-
-| 1
-| Escrow Number
-| 1
-| uInt
-| Links the withdrawal-request to a specific escrow.
-|-
-| 2
-| WT^
-| 32
-| hex
-| This is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a withdrawal-attempt.
-|-
-| 3
-| ACKs*
-| 2
-| uInt
-| The current total number of "votes", this starts at 0 and remains there throughout the waiting period.
-|-
-| 4
-| Age*
-| 3
-| uInt
-| Total duration of time, in blocks, that this WT^ has been inside of D2.
-|-
-| 5
-| Waiting Period*
-| 2
-| uInt
-| Total duration of time, in blocks, that this entry must sit idle, before it can begin to accumulate ACKs/NACKs. Pulled from D1's field #6.
-|-
-| 6
-| Max Age*
-| 3
-| uInt
-| Determined by summing (D1's field #6) and (D1's field #7).
-|-
-| 7
-| Threshold*
-| 2
-| uInt
-| Total ACKs needed, this is pulled from D1's field #9.
-|-
-| 8
-| Approved*
-| 1
-| boolean
-| True while ACKs > Threshold, False otherwise.
-|}
-
-\* Denotes a "convenience field" (see above).
-
-Withdrawal_DB requires 46 bytes [1+32+2+3+2+3+2+1] per entry. Of these, 13 bytes ([2+3+2+3+2+1], all fields except #1 and #2) can be generated locally, leaving 33 critical bytes [1+32].
-
-==== New Block Validation Rules for D2 ====
-
-# In each block, a hash commitment to D2 must always exist (even if D2 is blank).
-# D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort.
-# From one block to the next, every entry's "Age" field must increase by exactly 1.
-# From one block to the next, entries are only removed from D2 (in the very next block) if:
-## "Age" = "MaxAge".
-## If the block contains a txn who's blinded txID matches WT^. {{ This might be unnecessary, and a lot of work. }}
-# In addition, there are special rules for the allowed values in the "ACKs" field (field #3). See M4 below.
-
-==== M3 -- "Propose Withdrawal" ====
-
-    1-byte - OP_RETURN (0x6a)
-    1-byte - Push the following 37 bytes (0x25)
-    4-byte - Commitment header (0xD45AA943)
-    33-byte - the critical bytes mentioned above (fields #1 and #2, to populate a new D2 entry)
-
-
-==== New Block Validation Rules for M3 ====
-
-# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting values of fields #3 and #4 are zero, and #5 is pulled over by extracting the relevant value from D1.
-# Each block can only contain one M3 per sidechain.
-
-
-==== M4 -- "ACK Withdrawal" ====
-
-==== Very Little Info, Probably Calculable in Advance ====
-
-M4 is exceptional (in comparison to the other M's) in a few ways. First, its content is not stored anywhere, only the *hash* of its *effect* is stored (in a leaf of a merkle tree who's root is inserted into a mainchain coinbase). M4 alters the contents of D2 -- the *contents* of D2 are consensus critical, but M4 (the process by which nodes reach a new valid D2) can be anything.
-
-In fact, M4 can also be *nothing*. In other words, it may be optional. This is precisely because, from one block to the next, we have constrained D2 such that it is only allowed to change in a few ways. Therefore, the exhaustive set of "candidate D2s" can be precomputed by full nodes in advance.
-
-==== A Recent Change: Two Withdrawals at Once ====
-
-The following sections assume a maximum of one sucessful withdrawal per sidechain at a time. In other words, as WT^s are proposed, only one can make progress toward the finish line. As a result, a given side-to-main transfer will always take between 3 and 6 months. If there were more simulataneous withdrawals, the worst-case transfer duration would improve.
-
-<img src="bip-hashrate-escrows/two-groups.png?raw=true" align="middle"></img>
-
-The worst-case withdrawal time obeys f(n)=3+(3/n) months, where n is the number of simultaneous withdrawals.
-
-N=2 is the most desirable choice for several reasons. First, it delievers the greatest marginal benefit (of 1.5 months). Later choices only deliver 0.5 and 0.25 marginal months.
-
-Second, n=2 can be implemented in a clever way: by allowing a withdrawal to freely advance, if and only if has an ACK-score of 6575 or greater, and if it also has the largest ACK score. In other words, the withdrawal that is furthest along can advance (or retreat) for free, if it has already made it at least halfway to the finish line. With this change, our new M4, is either an "abstain" for the sidechain (in which case nothing happens to any ACK scores), or else it will be in one of two cases: old_M4 + "the largest advances", or new_M4 + "the largest retreats". As a result the number of M4 possibilities (of which the next section is concerned) only increases by a factor of two (instead of exponentially).
-
-It is possible to troll this rule, by getting two (or even three) withdrawals to have 6575+ ACK scores, and then getting them to *tie* for first place. So, if there are any ties, the ability to "bonus move" is disabled until all ties are broken.
-
-==== How Hard is it to Guess M4? ====
-
-If there are n Escrows and m Withdrawals-per-escrow<sup>1</sup>, then there are (m+2)^n total candidates for the next D2. This is because, [per block per escrow], one of three things can happen: (1) one of the m withdrawal-candidates can be "ACK"ed (or "upvoted" or "promoted"), which automatically downvotes the others; or (2) all withdrawal-candidates can be downvoted, or finally (3) the miners can abstain from voting on the escrow's withdrawals altogether, leaving the tallies the same.
-
-First, for nodes which validate all sidechains (assuming these escrows are sidechains), this simplifies to 2^n -- these nodes only have to choose between the single honest choice (on one hand) or an abstention (on the other). Second, even for nodes that don't validate any sidechains, the number of candidates might be reduced from m^n to 3^n, by making a simplifying assumption: whichever withdrawal was most recently added/upvoted, is likely to be the one which is upvoted next.
-
-Of course, that is still O(k^n) for n sidechains, which isn't great<sup>2</sup>. If the "D2 update" cannot be guessed, it must be transmitted in some way.
-
-==== Giving Up and Getting M4 the Old Fashioned Way ====
-
-Two examples for transmitting it are below:
-
-"Short Form" (Assumes there are no more than 254 active withdrawal-attempts per account)
-
-    4-byte - Message identifier (0x????????)
-    1-byte - Version of this message
-    N-byte - N is the total number of active accounts ("sidechains"), each byte specifies the position of the single WT that was "upvoted". A value of 0 indicates "downvote everything", a value of 255 indicates abstention.
-
-"Long Form" (Makes no assumptions about anything)
-
-    4-byte - Message identifier (0x????????)
-    1-byte - Version of this message
-    1-byte - Length (in bytes) of this message; total number of withdrawal attempts; y = ceiling( sum_i(m_i +2)/8 ). Nodes should already know what length to expect, because they know the sequence of M3s and therefore the vector of WT^s.
-    Y-byte - stream of bits (not bytes), with a 1 indicating the position of the chosen action [downvote all, abstain, upvote1, upvote2, ...]
-
-
-If the message is very very large, then nodes may not want to broadcast it. This opens up an "exhaustion attack"<sup>2</sup>, in which many miners create bad WT^s, vote on these randomly, and then refuse to broadcast their votes. Fortunately, even for a worst-case scenario of 200 sidechains and 1,000 withdrawal-attempts per sidechain, honest nodes can communicate a long form M4 with each other by using just 25,056 bytes per block [4+1+1+(200\*(1000+1+1)/8)].
-
-Today's pre-drivechain miners can already carry out a similar attack, by creating and including txns and then not broadcasting that part of the block to anyone. This is often characterized as a  [https://petertodd.org/2016/block-publication-incentives-for-miners "block publication incentive"], because in that case the prospect of exhaustively computing all possible transactions (to uncover the missing ones) is completely out of the question.
-
-However, message M4 is different from a withheld-txn, because M4 operates outside of the block's mandated information-processing limits (ie, outside the infamous 1 MB nonwitness blocksize limit). So we should examine the conditions under which M4 grows and shrinks, to ensure that we are not smuggling in a tremendous burden on full nodes.
-
-Under adversarial conditions, to lengthen a long-form M4 by one bit per block, for C blocks, the attacker must pay 312 bits (39 bytes) one time (to embed a new M3 message). The value C is the length of the sidechain's voting period, which varies but which I expect to be approximately 8,064 (and which could theoretically be as high as 65,536). Thus the attacker can burden nodes disproportionately, if (s)he wishes.
-
-Fortunately, the attack in question has no motivation (as far as I can tell). If the miner's goal is to trick rivals into mining on top of invalid blocks, he can already do this much more effectively with the unpublished-txn method (above). If instead he is just trying to harass nodes, then nodes may freely "downgrade" to earlier versions of the protocol, and simply ignore all drivechain-related messages. It seems that the attack could best be used in order to: make a large D2, make D2 confusing, sneak in votes for evil WT^ lurking in D2. Thus, the attack disables the transparency of the drivechain system, to some extent. The cost of the attack is forgone transaction fees, due to block space wasted on useless M3s.
-
-In practice, n is already capped, and miners may impose [on each other] a "soft cap" on m for their mutual protection. Thus, n and m might never get above 10 and 30, respectfully. In this case, the [Short Form, this time] M4 can never require more than 15 bytes per block, no matter what the attacker tries.
-
-In practice, m should always be 1 or 2, else something fishy is going on; and m can only inch up by 1 unit per block. So the system as a whole is still quite transparent, in that users are warned appropriately and well in advance. Attackers must invest upfront and they face an uphill climb, in order to eventually make things more expensive for a few others; defenders can wait-and-see if the attack looks like it will ever amount to anything before lifting a finger.
-
-
-===== New Block Validation Rules (for D2 and, by implication, M4) =====
-
-From one block to the next, D2 can only be edited in a few strict ways:
-
-* Entries can only be added/removed from D2 if they meet the criteria above (in M3, and implicitly M1 and M2).
-* The ACK-counter of any individual entry can only change by (-1,0,+1) relative to its previous entry.
-* Within a sidechain group, upvoting one withdrawal (ACK=ACK+1) requires you to downvote all other withdrawals in that group. However, the minimum ACK value is zero (and, therefore, downvotes cannot reduce it below zero).
-
-===== Footnotes for M4 =====
-
-<sup>1</sup> This represents the worst-case scenario is one where all the Withdrawals are spread evenly over each Sidechain. Under normal operations, there is no reason to expect the all sidechains will have the same number of withdrawals at any given time. In fact, under normal operations, the very *concept* of counting the withdrawals-per-sidechain should be a purposeless one, because there should only be *one* withdrawal at a time. Nonetheless we consider the worst case scenario here.
-
-<sup>2</sup> Guessing becomes more computationally intensive in a highly adversarial situation where the "limited range" is intentionally expanded. In such a scenario, [a] there are many sidechains, and [b] miners voluntarily sacrifice their scarce block-space by creating a high number of (mutually-exclusive, and hence ultimately invalid) withdrawal attempts and putting these into coinbase transactions; and then agree to all [c] vote on these randomly (guaranteeing that all withdrawals fail, including any true withdrawals) and [d] successfully withhold their random voting strategies from nodes (even including spy-miner-nodes). Under this bizarre scenario, nodes may require computing resources which increase near-exponentially with the number of withdrawals, and it may take a long time for an ignorant node to exhaustively work out the underlying state of Withdrawal_DB. In this case, nodes may decide to temporarily stop validating such transactions (as if they had not yet upgraded to support this soft fork).
-
-
-
-=== Depositing and Withdrawing (M5, M6) ===
-
-
-Both M5 and M6 are regular Bitcoin txns. They are identified by meeting an important criteria: they select a one of the Critical TxID-index Pairs (a "CTIP") as one of their inputs. Deposits ("M5") are distinguished from withdrawals ("M6") by simply checking to see if money is "going in", or "out". In other words, we compare the BTC value of the original CTIP to that of new CTIP. If original <= new it is a deposit, if original > new then it is a withdrawal.
-
-The code that identifies sidechain withdrawal / deposit txns (by calculating how much value is being put into or taken out of a sidechain) can be seen here: https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L351-L386
-
-Such txns are forced (by consensus) to obey two additional criteria:
-
-# They must contain an output paying "to" the Critical Address [probably in TxOut0].
-# They must be accompanied by an update to this sidechain's Critical TxID-index Pair (CTIP). The new CTIP must be "this" txn itself.
-
-These criteria are enforced [https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 here] by checking that a deposit is paying back to the sidechain more than it is taking out, and completely rejecting any withdrawal from the mempool. And [https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 here] we allow for a withdrawal only once it has attained sufficient work score (ACKs).
-
-The purpose of this is to have all of the escrow's money (ie all of the sidechain's money) in one TxID, so that depositors immediately undo any UTXO bloat they may cause. This simplifies the withdrawal process, as there is no need to worry about cleaning up "dust deposits" (...and such cleaning can often result in headaches, for example where a withdrawal-txn is larger than 1MB in size, or else may only withdraw an arbitrarily limited amount of BTC). Notice that, unless we assume that an account will last forever, all utxos which are deposited must eventually be withdrawn by someone. Therefore, the relevant design criterion is not "efficiency" (total network cost) but rather "who should pay" (allocation of costs).
-
-==== M5. "Make a Deposit" -- a transfer of BTC from-main-to-side ====
-
-As far as mainchain consensus is concerned, there are no additional requirements.
-
-However, in practice there *are* additional mainchain requirements...specified by the escrow account, (ie specified by the "sidechain" or "virtual chain"). These requirements are not part of mainchain consensus and are allowed to be anything. In other words, the sidechain is free to invent any way to credit depositor's money -- M5 is fully customizable.
-
-One method, is for mainchain depositors to append a zero-value OP Return to a Deposit txn, so that the sidechain knows how to credit funds. Mainchain users must upgrade their wallet software, of course, (on an individual basis) in order to become aware of and take advantage of new deposit-methods.
-
-===== Inconvenient Race Condition =====
-
-The requirement that each hashrate escrow be linked to a single TxID does create an interesting inconvenience for depositors. If a user is slow to sign a txn after constructing it (perhaps because the user employs an air-gapped computer, etc), then the signed txn may no longer be valid. This is because the input it selects, may no longer be the Critical TxID (as "the" Critical TxID changes with each deposit). **Only one user can deposit at a time** (although many can deposit per block). As a result, the transaction must fail, and the user would need to be prompted to remake and resign the txn. If this is problem is too frustrating, users can always make main-to-side transfers using atomic cross chain swaps (or, the LN, if they already have a channel open on both chains).
-
-Fortunately, it is already a part of mainchain consensus that no two txns can spend the same TxID. The only new issue here is the confusion it might create for the user (hence the need for error messages and alternative deposit-methods).
-
-
-==== M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main ====
-
-We come, finally, to the critical matter: where users can take their money *out* of the escrow account, and return it to the "regular" UTXO set. As previously mentioned, this txn is one which (a) spends from a CTIP and (b) reduces the quantity of BTC in an account's CTIP. Most of the work has already been done by D1, M3, M4, and D2. Furthermore, existing Bitcoin tx-rules prevent the sidechain from ever withdrawing more money than has been placed into it.
-
-From there, we merely introduce two final concepts:
-
-# In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140.
-# A "blinded TxID" is way of hashing the txn, in which we first overwrite some parts of the txn with zeros. Specifically, the first 36 bytes of "TxIn0" (the first input, including TxOutHash and TxOutIndex), as well as the first 8 bytes of "TxOut0" (the first output).
-
-Blinding is necessary because we allow each sidechain only one UTXO at a time.
-
-of our restriction of the account to a single UTXO-member. Because of this, during the ACKing process the withdrawal-txn (which is currently being ACKed) may change in two ways: the CTIP (which changes with each deposit), and the total quantity of BTC stored in the account (which arbitrarily increases with each new deposit). In other words, a withdrawal-attempt is created via M3, but this takes place many blocks before the withdrawal is actually included via M6. During this time, a single new deposit to the account would change its CTIP and its value. So, what do we ACK? Well, we ACK a "blinded" version of the withdrawal. This blinded version is stable because the dynamic parts are always overwritten with zeros.
-
-While we ACK a blinded WT^, what is actually included in the blockchain ("M6") is an unblinded WT^. Since each blinded WT^ could correspond to many different unblinded WT^s, we need to impose further restrictions on those unblinded WT^s that are finally included. First, we will force the final unblinded WT^ to spend the entire sidechain balance (by forcing sum(input_values) to equal sum(output_values)). To avoid withdrawing the entire sidechain balance with every withdrawal, we will, secondly, force the unblinded WT^ to create a new output which is itself a deposit to the sidechain it withdrew from (which nodes can check using D1's CTIP field). Unfortunately, these requirements eliminate the possibility of including a transaction fee, as traditionally calculated. So, finally, to compensate for *that*, txn fees are encoded explicitly as a withdrawal to OP_TRUE (which the main:block's miner can immediately claim).
-
-With all of this in place, the only requirements for inclusion in a block are these:
-
-# "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block.
-# "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn.
-# "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible.
-
-Finally, don't forget that M6 inherits the requirement (common to both M5 and M6) that the CTIP be selected as an input, and that the CTIP then be updated. In this case, we know that the critical index will be zero, so the new CTIP will be ("this TxID" (NOT blinded), 0). The TxID is NOT blinded because blinding is only for accumulating ACKs.
-
-As a result of these requirements, every single withdrawal-attempt will fail, unless an entry has been added to D2 and "ACKed" a sufficient number of times.
-
-
-
-==Backward compatibility==
-
-
-As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving the UTXO in single, infrequent bursts. However, this phenomena doesn't affect them or the validity of the money that they receive.
-
-( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that the WT^s reported by different clients will continue to match identically, is to upgrade sidechains via soft forks of themselves. )
-
-
-==Deployment==
-
-
-This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" and using bit 4.
-
-<pre>
-// Deployment of Drivechains (BIPX, BIPY)
-consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
-consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1515974401; // January 15th, 2018.
-consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1547510401; // January 15th, 2019.
-</pre>
-
-==Reference Implementation==
-
-
-See: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
-
-Also, for interest, see an example sidechain here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
-
-
-==References==
-
-See http://www.drivechain.info/literature/index.html
-
-
-==Credits==
-
-Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Chris Stewart, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Ben Goldhaber.
-
-
-==Copyright==
-
-This BIP is licensed under the BSD 2-clause license.
diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png
deleted file mode 100644
index c8a3ffa..0000000
--- a/bip-hashrate-escrows/two-groups.png
+++ /dev/null