Update Bip300

Author: psztorc

bip-0300.mediawiki

@@ -179,13 +179,7 @@ First, how are new sidechains created?
 
 They are first proposed (with M1), and later acked (with M2). This process resembles Bip9 soft fork activation.
 
-==== M1 and M2 (Adding a new sidechain) ====
-
-Examples:
-
-<img src="bip-0300/m1-gui.jpg?raw=true" align="middle"></img>
-
-<img src="bip-0300/m1-cli.png?raw=true" align="middle"></img>
+==== M1 -- Propose Sidechain ====
 
 M1 is a coinbase OP Return output containing the following:
 
@@ -202,47 +196,67 @@ M1 is a coinbase OP Return output containing the following:
       32-byte hashID1
       20-byte hashID2
 
+===== Examples =====
+
+<img src="bip-0300/m1-gui.jpg?raw=true" align="middle"></img>
+
+<img src="bip-0300/m1-cli.png?raw=true" align="middle"></img>
+
+==== M2 -- ACK Sidechain Proposal ====
+
 M2 is a coinbase OP Return output containing the following:
 
     1-byte - OP_RETURN (0x6a)
     4-byte - Message header (0xD6E1C5BF)
     32-byte - sha256D hash of sidechain's serialization
 
+===== Notes =====
+
 The new M1/M2 validation rules are:
 
-# Any miner can propose a new sidechain at any time. This procedure resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 90% of the following 2016 blocks.
-# It is possible to "overwrite" a sidechain. This requires more ACKs -- 50% of the following 26300 blocks must contain an M2. The possibility of overwrite, does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26300 blocks).
+# Any miner can propose a new sidechain (M1) at any time. This procedure resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain (M2) in 90% of the following 2016 blocks.
+# Bip300 comes with only 256 sidechain-slots. If all are used, it is possible to "overwrite" a sidechain. This requires vastly more M2 ACKs -- 50% of the following 26300 blocks must contain an M2. The possibility of overwrite, does not change the Bip300 security assumptions (because we already assume that the sidechain is vulnerable to miners, at a rate of 1 catastrophe per 13150 blocks).
+
+
 
+==== Notes on Withdrawing Coins ====
 
-==== M3 and M4 (Withdrawing Coins) ====
+Bip300 withdrawals ("M6") are very significant.
 
-Withdrawals in Bip300 (ie, "M6"), are very significant. So, we will first discuss how these are approved/rejected -- a process involving M3, M4, and D2.
+For an M6 to be valid, it must be first "prepped" by one M3 and then 13,150+ M4s. M3 and M4 are about "Bundles".
 
 ===== What are Bundles? =====
 
-All Bip300 withdrawals take the form of “Bundles” -- named because they "bundle up" many individual withdrawal-requests into one single rare layer1 transaction.
+Sidechain withdrawals take the form of “Bundles” -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
+
+Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
+
+This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course). 
+
+A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
 
-This bundle either pays all of the withdrawals out, or else it fails (and pays nothing out). Bip300 / layer 1 does not assemble Bundles (the sidechain developer does this, in a manner of their choosing).
+===== Bundle Hash = Blinded TxID of M6 =====
 
-Bundles are identified by a 32-byte hash, which aspires to be the TxID of M6. Unfortunately, the Bundle-hash and M6-TxID cannot match exactly, since the first input to M6 is a CTIP which is constantly changing. So, we must accomplish a task, which is conceptually similar to AnyPrevOut (BIP 118). We define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. In our case, the precise "overwritten bytes" are: the first input and the first output.
+The Bundle hash is static as it is being ACKed. Unfortunately, the M6 TxID will be constantly changing -- as users deposit to the sidechain, the input to M6 will change.
 
-===== M3 (Propose a Bundle) =====
+To solve this problem, we do something conceptually similar to AnyPrevOut (BIP 118). We define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. These are: the first input and the first output. Via the former, a sidechain can accept deposits, even if we are acking a TxID that spends from it later. Via the latter, we can force all of the non-withdrawn coins to be returned to the sidechain (even if we don't yet know how many coins this will be).
+
+==== M3 -- Propose Bundle ====
 
 M3 is a coinbase OP Return output containing the following:
 
     1-byte - OP_RETURN (0x6a)
     4-byte - Commitment header (0xD45AA943)
     32-byte - The Bundle hash, to populate a new D2 entry
 
-
 The new validation rules pertaining to M3 are:
 
 # If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting "Blocks Remaining" value is 26,299. The starting ACKs count is 1.
 # Each block can only contain one M3 per sidechain.
 
 Once a Bundle is in D2, how can we give it enough ACKs to make it valid?
 
-===== M4 (ACK Withdrawals) =====
+==== M4 -- ACK Bundle(s) ====
 
 M4 is a coinbase OP Return output containing the following:
 
@@ -251,7 +265,9 @@ M4 is a coinbase OP Return output containing the following:
     1-byte - Version
     n-byte - The vector describing the "upvoted" bundle-choice, for each sidechain.
 
-Version 0x01 uses one byte per sidechain, and applies in most cases. Version 0x02 uses two bytes per sidechain and applies in unusual situations where at least one sidechain has more than 256 distinct withdrawal-bundles in progress at one time. If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
+Version 0x01 uses one byte per sidechain, and applies in most cases. Version 0x02 uses two bytes per sidechain and applies in unusual situations where at least one sidechain has more than 256 distinct withdrawal-bundles in progress at one time. Other interesting versions are possible: 0x03 might say "do exactly what was done in the previous block" (which could consume a fixed 6 bytes total, regardless of how many sidechains). 0x04 might say "upvote everyone who is clearly in the lead" (which also would require a mere 6 bytes), and so forth.
+
+If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
 
 The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". For example, if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the vector would be 0x0704.
 
@@ -263,39 +279,35 @@ Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote al
 
 Finally, we describe Deposits and Withdrawals.
 
-==== M5 and M6 (User's Deposits and Withdrawals) ====
 
-Both M5 and M6 are regular Bitcoin txns. They are identified, as Deposits/Withdrawals, when they select one of the special CTIP UTXOs as one of their inputs (see D1).
+==== M5 -- Deposit BTC to Sidechain ====
 
-All of a sidechain’s coins, are stored in one UTXO. (Deposits/Withdrawals never cause UTXO bloat.) So, each Deposit/Withdrawal must select a CTIP, and generate a new CTIP (this is tracked in D1, above).
+Both M5 and M6 are regular Bitcoin txns. They are distinguished from regular txns (non-M5 non-M6 txns), when they select one of the special Bip300 CTIP UTXOs as one of their inputs (see D1).
 
-If the from-CTIP-to-CTIP quantity of coins goes '''up''', (ie, if the user is adding coins), then the txn is treated as a Deposit (M5). Else it is treated as a Withdrawal (M6). See [https://github.com/drivechain-project/mainchain/blob/e37b008fafe0701b8313993c8b02ba41dc0f8a29/src/validation.cpp#L667-L780 here].
+All of a sidechain’s coins, are stored in one UTXO, called the "CTIP". Every time a deposit or withdrawal is made, the CTIP changes. Each deposit/withdrawal will select the sidechains CTIP, and generate a new CTIP. (Deposits/Withdrawals never cause UTXO bloat.) The current CTIP is cached in D1 (above).
 
-
-===== M5 (Make a Deposit) -- a transfer of BTC from-main-to-side =====
+If the '''quantity of coins''', in the from-CTIP-to-CTIP transaction, goes '''up''', (ie, if the user is adding coins), then the txn is treated as a Deposit (M5). Else it is treated as a Withdrawal (M6). See [https://github.com/drivechain-project/mainchain/blob/e37b008fafe0701b8313993c8b02ba41dc0f8a29/src/validation.cpp#L667-L780 here].
 
 As far as mainchain consensus is concerned, all deposits to a sidechain are always valid.
 
-===== M6 (Execute a Withdrawal) -- a transfer of BTC from-side-to-main =====
+===== M6 -- Withdraw BTC from a Sidechain =====
 
 We come, finally, to the critical matter: where users can take their money *out* of the sidechain.
 
-In each block, a Bundle in D2 is considered "approved" if its "ACK-counter" value meets the threshold (13,150).
-
-If a Bundle is approved, then its associated M6 can be included in a block.
+First, M6 must obey the same CTIP rules of M5 (see immediately above).
 
-An M6 must meet all these criteria, else it be invalid:
+Second, an M6 is only valid for inclusion in a block, if its blinded TxID matches an "approved" Bundle hash (ie, one with an ACK score of 13150+). In other words, an M6 can only be included in a block, after the 3+ month (13150 block) ceremony.
 
-# "Be ACKed" -- The "blinded TxID" of the M6 must match an approved Bundle. In other words, an M6 can only be included in a block, after the 3+ month (13150 block) ceremony.
-# "Return Change to Account" -- TxOut0 must be paid back to the sidechain's Bip300 script. In other words, since we select the UTXO with *all* of the money, we must make sure we pay all of the non-withdrawn money back into the sidechain.
-# "Return *all* Change to Account" -- Sum of all inputs must equal the sum of all outputs. No traditional tx fee is possible. (The txn fee is paid via an OP TRUE output in the Bundle -- this allows the withdraw-ers to set the fee via the Bundle, and ACK it over 3 months like everything else.)
+Third, M6 must meet two accounting criteria, lest it be invalid:
+# "Give change back to Escrow" -- The first output, TxOut0, must be paid back to the sidechain's Bip300 script. In other words, all non-withdrawn coins must be paid back into the sidechain.
+# "No traditional txn fee" -- For this txn, the sum of all inputs must equal the sum of all outputs. No traditional tx fee is possible. (Of course, there is still a txn fee for miners: it is paid via an OP TRUE output in the Bundle.) We want the withdraw-ers to set the fee "inside" the Bundle, and ACK it over 3 months like everything else.
 
 
 ==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, these phenomena don't affect them, or the validity of the money that they receive.
+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 these UTXOs in single, infrequent bursts. However, these phenomena don'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 a sidechain's Bundles will continue to match identically, is to upgrade sidechains via soft forks of themselves. )
+( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that all different sidechain-nodes will always report the same Bundle, is to upgrade sidechains via soft forks of themselves. )
 
 
 ==Deployment==