From 0a1d35877a993b460c14358324cf545a53d852ff Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:30:10 -0500 Subject: Create images.txt --- bip-hashrate-escrows/images.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 bip-hashrate-escrows/images.txt diff --git a/bip-hashrate-escrows/images.txt b/bip-hashrate-escrows/images.txt new file mode 100644 index 0000000..ece458d --- /dev/null +++ b/bip-hashrate-escrows/images.txt @@ -0,0 +1 @@ +Images used in this bip. -- cgit v1.2.3 From db86b890f92015ba50d6b1b49ba742a4b28663fc Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:30:22 -0500 Subject: Add files via upload --- bip-hashrate-escrows/two-groups.png | Bin 0 -> 39695 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 bip-hashrate-escrows/two-groups.png diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png new file mode 100644 index 0000000..c8a3ffa Binary files /dev/null and b/bip-hashrate-escrows/two-groups.png differ -- cgit v1.2.3 From 2580d6522831bd8d3967515bee4429fd6a6351a6 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:32:48 -0500 Subject: Add files via upload --- bip-hashrate-escrows.md | 408 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 408 insertions(+) create mode 100644 bip-hashrate-escrows.md diff --git a/bip-hashrate-escrows.md b/bip-hashrate-escrows.md new file mode 100644 index 0000000..3b5d61e --- /dev/null +++ b/bip-hashrate-escrows.md @@ -0,0 +1,408 @@ + +Header +======= + + BIP: ???? + Layer: Consensus (soft fork) + Title: Hashrate Escrows (Consensus layer) + Author: Paul Sztorc + CryptAxe + 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 + + +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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). + + +Motivation +============ + +In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). + +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 + +1. D1 will always exist. +2. 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. +3. D1 is updated according to M1 and M2 (below). +4. 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 + +1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. +2. 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. + + +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 + +1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). +2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. +3. From one block to the next, every entry's "Age" field must increase by exactly 1. +4. 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. }} +5. 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 + +1. 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. +2. 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. + +#### Two Withdrawals at Once + +In general, only one withdrawal (per sidechain) can make progress (toward being included in a block) 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. Instead, with more simultaneous withdrawals, the worst-case transfer duration would improve. + +![dots-image](/bip-hashrate-escrows/two-groups.png?raw=true) + +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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 + +1 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. + +2 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: + +1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. +2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: + +1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. +2. 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: + +1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. +2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. +3. "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. + +``` +// 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 +============ + +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. -- cgit v1.2.3 From da2e5745f3dcf801e9ab50939791d6cecf434c11 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:36:40 -0500 Subject: Add files via upload --- bip-blind-merged-mining.md | 329 ++++++++++++++++++++++++ bip-blind-merged-mining/bmm-dots-examples.png | Bin 0 -> 41116 bytes bip-blind-merged-mining/images.txt | 1 + bip-blind-merged-mining/witness-vs-critical.png | Bin 0 -> 67570 bytes 4 files changed, 330 insertions(+) create mode 100644 bip-blind-merged-mining.md create mode 100644 bip-blind-merged-mining/bmm-dots-examples.png create mode 100644 bip-blind-merged-mining/images.txt create mode 100644 bip-blind-merged-mining/witness-vs-critical.png diff --git a/bip-blind-merged-mining.md b/bip-blind-merged-mining.md new file mode 100644 index 0000000..ee81f1f --- /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 + CryptAxe + Chris Stewart + 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 Binary files /dev/null and b/bip-blind-merged-mining/bmm-dots-examples.png differ diff --git a/bip-blind-merged-mining/images.txt b/bip-blind-merged-mining/images.txt new file mode 100644 index 0000000..00b3932 --- /dev/null +++ b/bip-blind-merged-mining/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. 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 Binary files /dev/null and b/bip-blind-merged-mining/witness-vs-critical.png differ -- cgit v1.2.3 From 1af547cf728d27070b3c90ce02c3a7731bb5dcd6 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:38:23 -0500 Subject: Delete bip-hashrate-escrows.md --- bip-hashrate-escrows.md | 408 ------------------------------------------------ 1 file changed, 408 deletions(-) delete mode 100644 bip-hashrate-escrows.md diff --git a/bip-hashrate-escrows.md b/bip-hashrate-escrows.md deleted file mode 100644 index 3b5d61e..0000000 --- a/bip-hashrate-escrows.md +++ /dev/null @@ -1,408 +0,0 @@ - -Header -======= - - BIP: ???? - Layer: Consensus (soft fork) - Title: Hashrate Escrows (Consensus layer) - Author: Paul Sztorc - CryptAxe - 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 - - -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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). - - -Motivation -============ - -In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). - -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 - -1. D1 will always exist. -2. 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. -3. D1 is updated according to M1 and M2 (below). -4. 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 - -1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. -2. 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. - - -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 - -1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). -2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. -3. From one block to the next, every entry's "Age" field must increase by exactly 1. -4. 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. }} -5. 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 - -1. 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. -2. 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. - -#### Two Withdrawals at Once - -In general, only one withdrawal (per sidechain) can make progress (toward being included in a block) 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. Instead, with more simultaneous withdrawals, the worst-case transfer duration would improve. - -![dots-image](/bip-hashrate-escrows/two-groups.png?raw=true) - -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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 - -1 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. - -2 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: - -1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. -2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: - -1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. -2. 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: - -1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. -2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. -3. "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. - -``` -// 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 -============ - -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. -- cgit v1.2.3 From 4bea2ef2b67a996c040d026df61cdaf470c9de53 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:40:43 -0500 Subject: one bip at a time --- bip-hashrate-escrows.md | 408 ------------------------------------ bip-hashrate-escrows/images.txt | 1 - bip-hashrate-escrows/two-groups.png | Bin 39695 -> 0 bytes 3 files changed, 409 deletions(-) delete mode 100644 bip-hashrate-escrows.md delete mode 100644 bip-hashrate-escrows/images.txt delete mode 100644 bip-hashrate-escrows/two-groups.png diff --git a/bip-hashrate-escrows.md b/bip-hashrate-escrows.md deleted file mode 100644 index 3b5d61e..0000000 --- a/bip-hashrate-escrows.md +++ /dev/null @@ -1,408 +0,0 @@ - -Header -======= - - BIP: ???? - Layer: Consensus (soft fork) - Title: Hashrate Escrows (Consensus layer) - Author: Paul Sztorc - CryptAxe - 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 - - -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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). - - -Motivation -============ - -In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). - -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 - -1. D1 will always exist. -2. 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. -3. D1 is updated according to M1 and M2 (below). -4. 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 - -1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. -2. 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. - - -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 - -1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). -2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. -3. From one block to the next, every entry's "Age" field must increase by exactly 1. -4. 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. }} -5. 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 - -1. 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. -2. 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. - -#### Two Withdrawals at Once - -In general, only one withdrawal (per sidechain) can make progress (toward being included in a block) 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. Instead, with more simultaneous withdrawals, the worst-case transfer duration would improve. - -![dots-image](/bip-hashrate-escrows/two-groups.png?raw=true) - -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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 - -1 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. - -2 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: - -1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. -2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: - -1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. -2. 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: - -1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. -2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. -3. "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. - -``` -// 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 -============ - -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/images.txt b/bip-hashrate-escrows/images.txt deleted file mode 100644 index ece458d..0000000 --- a/bip-hashrate-escrows/images.txt +++ /dev/null @@ -1 +0,0 @@ -Images used in this bip. diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png deleted file mode 100644 index c8a3ffa..0000000 Binary files a/bip-hashrate-escrows/two-groups.png and /dev/null differ -- cgit v1.2.3 From 39a8bec6b7b7ca7e7fa405e7f43703684f5fa1e8 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:42:45 -0500 Subject: Delete images.txt --- bip-hashrate-escrows/images.txt | 1 - 1 file changed, 1 deletion(-) delete mode 100644 bip-hashrate-escrows/images.txt diff --git a/bip-hashrate-escrows/images.txt b/bip-hashrate-escrows/images.txt deleted file mode 100644 index ece458d..0000000 --- a/bip-hashrate-escrows/images.txt +++ /dev/null @@ -1 +0,0 @@ -Images used in this bip. -- cgit v1.2.3 From 3246096174020bdcfcdf464c43b0ec997410f580 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 3 Feb 2018 21:42:52 -0500 Subject: Delete two-groups.png --- bip-hashrate-escrows/two-groups.png | Bin 39695 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 bip-hashrate-escrows/two-groups.png diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png deleted file mode 100644 index c8a3ffa..0000000 Binary files a/bip-hashrate-escrows/two-groups.png and /dev/null differ -- cgit v1.2.3 From 8a8c6253bef170b57c91c8e129d977ae27e3f530 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 14:01:25 -0500 Subject: re-reverse the bips this is what I originally intended, but I forked this branch at the wrong time --- bip-blind-merged-mining.md | 329 ------------------- bip-blind-merged-mining/bmm-dots-examples.png | Bin 41116 -> 0 bytes bip-blind-merged-mining/images.txt | 1 - bip-blind-merged-mining/witness-vs-critical.png | Bin 67570 -> 0 bytes bip-hashrate-escrows/images.txt | 1 + bip-hashrate-escrows/two-groups.png | Bin 0 -> 39695 bytes hashrate-escrows.md | 408 ++++++++++++++++++++++++ 7 files changed, 409 insertions(+), 330 deletions(-) delete mode 100644 bip-blind-merged-mining.md delete mode 100644 bip-blind-merged-mining/bmm-dots-examples.png delete mode 100644 bip-blind-merged-mining/images.txt delete mode 100644 bip-blind-merged-mining/witness-vs-critical.png create mode 100644 bip-hashrate-escrows/images.txt create mode 100644 bip-hashrate-escrows/two-groups.png create mode 100644 hashrate-escrows.md diff --git a/bip-blind-merged-mining.md b/bip-blind-merged-mining.md deleted file mode 100644 index ee81f1f..0000000 --- a/bip-blind-merged-mining.md +++ /dev/null @@ -1,329 +0,0 @@ - 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 - CryptAxe - Chris Stewart - 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 deleted file mode 100644 index 70f11f6..0000000 Binary files a/bip-blind-merged-mining/bmm-dots-examples.png and /dev/null differ diff --git a/bip-blind-merged-mining/images.txt b/bip-blind-merged-mining/images.txt deleted file mode 100644 index 00b3932..0000000 --- a/bip-blind-merged-mining/images.txt +++ /dev/null @@ -1 +0,0 @@ -Images used as reference in the documentation. diff --git a/bip-blind-merged-mining/witness-vs-critical.png b/bip-blind-merged-mining/witness-vs-critical.png deleted file mode 100644 index 1a2458d..0000000 Binary files a/bip-blind-merged-mining/witness-vs-critical.png and /dev/null differ diff --git a/bip-hashrate-escrows/images.txt b/bip-hashrate-escrows/images.txt new file mode 100644 index 0000000..2fbbf63 --- /dev/null +++ b/bip-hashrate-escrows/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png new file mode 100644 index 0000000..c8a3ffa Binary files /dev/null and b/bip-hashrate-escrows/two-groups.png differ diff --git a/hashrate-escrows.md b/hashrate-escrows.md new file mode 100644 index 0000000..a594b26 --- /dev/null +++ b/hashrate-escrows.md @@ -0,0 +1,408 @@ + +Header +======= + + BIP: ???? + Layer: Consensus (soft fork) + Title: Hashrate Escrows (Consensus layer) + Author: Paul Sztorc + CryptAxe + 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 + + +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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). + + +Motivation +============ + +In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). + +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 + +1. D1 will always exist. +2. 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. +3. D1 is updated according to M1 and M2 (below). +4. 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 + +1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. +2. 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. + + +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 + +1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). +2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. +3. From one block to the next, every entry's "Age" field must increase by exactly 1. +4. 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. }} +5. 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 + +1. 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. +2. 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. + +![dots-image](/images/two-groups.png?raw=true) + +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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 + +1 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. + +2 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: + +1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. +2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: + +1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. +2. 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: + +1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. +2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. +3. "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. + +``` +// 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 +============ + +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. -- cgit v1.2.3 From 99f553025fdf3bb3fd3f5ef9bd88846bfad1a8fa Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 16:30:07 -0500 Subject: mediawiki format --- bip-hashrate-escrows.mediawiki | 400 ++++++++++++++++++++++++++++++++++++++++ hashrate-escrows.md | 408 ----------------------------------------- 2 files changed, 400 insertions(+), 408 deletions(-) create mode 100644 bip-hashrate-escrows.mediawiki delete mode 100644 hashrate-escrows.md diff --git a/bip-hashrate-escrows.mediawiki b/bip-hashrate-escrows.mediawiki new file mode 100644 index 0000000..0f2210c --- /dev/null +++ b/bip-hashrate-escrows.mediawiki @@ -0,0 +1,400 @@ + + +
+    BIP: ????
+    Layer: Consensus (soft fork)
+    Title: Hashrate Escrows (Consensus layer)
+    Author: Paul Sztorc 
+            CryptAxe 
+    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
+
+ +==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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). + + +==Motivation== + +In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). + +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==== + +1. D1 will always exist. +2. 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. +3. D1 is updated according to M1 and M2 (below). +4. 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 ==== + +1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. +2. 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. + + +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 ==== + +1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). +2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. +3. From one block to the next, every entry's "Age" field must increase by exactly 1. +4. 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. }} +5. 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 ==== + +1. 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. +2. 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. + +![dots-image](/images/two-groups.png?raw=true) + +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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 ===== + +1 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. + +2 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: + +1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. +2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: + +1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. +2. 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: + +1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. +2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. +3. "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. + +``` +// 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== + +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/hashrate-escrows.md b/hashrate-escrows.md deleted file mode 100644 index a594b26..0000000 --- a/hashrate-escrows.md +++ /dev/null @@ -1,408 +0,0 @@ - -Header -======= - - BIP: ???? - Layer: Consensus (soft fork) - Title: Hashrate Escrows (Consensus layer) - Author: Paul Sztorc - CryptAxe - 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 - - -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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) 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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). - - -Motivation -============ - -In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) 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"). - -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 - -1. D1 will always exist. -2. 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. -3. D1 is updated according to M1 and M2 (below). -4. 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 - -1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. -2. 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. - - -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 - -1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). -2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. -3. From one block to the next, every entry's "Age" field must increase by exactly 1. -4. 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. }} -5. 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 - -1. 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. -2. 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. - -![dots-image](/images/two-groups.png?raw=true) - -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-escrow1, 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 great2. 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"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), 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 - -1 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. - -2 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: - -1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. -2. 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 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: - -1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. -2. 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: - -1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. -2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. -3. "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. - -``` -// 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 -============ - -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. -- cgit v1.2.3 From 9207df7d054c21cb276b6873f009be0fda992d93 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:00:23 -0500 Subject: fix mediawiki formatting --- bip-hashrate-escrows.mediawiki | 189 +++++++++++++++++++++++++++++------------ 1 file changed, 136 insertions(+), 53 deletions(-) diff --git a/bip-hashrate-escrows.mediawiki b/bip-hashrate-escrows.mediawiki index 0f2210c..82c436c 100644 --- a/bip-hashrate-escrows.mediawiki +++ b/bip-hashrate-escrows.mediawiki @@ -17,16 +17,16 @@ ==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 [a famous Oct 2014 paper](https://blockstream.com/sidechains.pdf) written partially by some Blockstream co-founders. +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 [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html). +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 [Rootstock](http://www.rsk.co/)) or "virtual chains" within Bitcoin (such as [proposed by Blockstack](https://github.com/blockstack/virtualchain) in mid-2016). +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: @@ -77,16 +77,55 @@ The table below enumerates the new database fields, their size in bytes, and the 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"). -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. - +{| 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). @@ -94,10 +133,10 @@ Escrow_DB requires 223 bytes [1+120+32+32+2+32+4] for each escrow in the main bl ====Notes on D1==== -1. D1 will always exist. -2. 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. -3. D1 is updated according to M1 and M2 (below). -4. 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). +# 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==== @@ -108,7 +147,7 @@ Miners have always upgraded their software according to criteria that are known 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 +===== 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. @@ -147,11 +186,11 @@ Currently, we use a process which may be suboptimal. It is that we *literally si ==== New Block Validation Rules ==== -1. 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 [version 1 Bitcoin addresses](https://en.bitcoin.it/wiki/Technical_background_of_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. -2. Only one M1 (of any kind) can be added into a block at a time. +# 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 ==== @@ -180,16 +219,61 @@ The escrow will "reuse" the same address over and over. But notice that there is The table below enumerates the database fields, their size (in bytes), type and purpose. -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. +{| 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). @@ -197,13 +281,13 @@ Withdrawal_DB requires 46 bytes [1+32+2+3+2+3+2+1] per entry. Of these, 13 bytes ==== New Block Validation Rules for D2 ==== -1. In each block, a hash commitment to D2 must always exist (even if D2 is blank). -2. D2 must always be sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. -3. From one block to the next, every entry's "Age" field must increase by exactly 1. -4. 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. }} -5. In addition, there are special rules for the allowed values in the "ACKs" field (field #3). See M4 below. +# 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" ==== @@ -215,8 +299,8 @@ Withdrawal_DB requires 46 bytes [1+32+2+3+2+3+2+1] per entry. Of these, 13 bytes ==== New Block Validation Rules for M3 ==== -1. 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. -2. Each block can only contain one M3 per sidechain. +# 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" ==== @@ -231,7 +315,7 @@ In fact, M4 can also be *nothing*. In other words, it may be optional. This is p 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. -![dots-image](/images/two-groups.png?raw=true) + The worst-case withdrawal time obeys f(n)=3+(3/n) months, where n is the number of simultaneous withdrawals. @@ -269,7 +353,7 @@ Two examples for transmitting it are below: If the message is very very large, then nodes may not want to broadcast it. This opens up an "exhaustion attack"2, 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 ["block publication incentive"](https://petertodd.org/2016/block-publication-incentives-for-miners), because in that case the prospect of exhaustively computing all possible transactions (to uncover the missing ones) is completely out of the question. +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. @@ -307,10 +391,10 @@ The code that identifies sidechain withdrawal / deposit txns (by calculating how Such txns are forced (by consensus) to obey two additional criteria: -1. They must contain an output paying "to" the Critical Address [probably in TxOut0]. -2. They must be accompanied by an update to this sidechain's Critical TxID-index Pair (CTIP). The new CTIP must be "this" txn itself. +# 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L440-L473 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 here https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/validation.cpp#L1747-L1757 we allow for a withdrawal only once it has attained sufficient work score (ACKs). +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). @@ -335,8 +419,8 @@ We come, finally, to the critical matter: where users can take their money *out* From there, we merely introduce two final concepts: -1. In each block, an entry in D2 is considered an "approved candidate" if the "ACKs" value is above 13140. -2. 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). +# 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. @@ -346,9 +430,9 @@ While we ACK a blinded WT^, what is actually included in the blockchain ("M6") i With all of this in place, the only requirements for inclusion in a block are these: -1. "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. -2. "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. -3. "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible. +# "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. @@ -394,7 +478,6 @@ See http://www.drivechain.info/literature/index.html 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. -- cgit v1.2.3 From 486505b8fad62cb3c2f01b1a0eb79b1912196fda Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:02:33 -0500 Subject: typos --- bip-hashrate-escrows.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-hashrate-escrows.mediawiki b/bip-hashrate-escrows.mediawiki index 82c436c..0987bf5 100644 --- a/bip-hashrate-escrows.mediawiki +++ b/bip-hashrate-escrows.mediawiki @@ -315,7 +315,7 @@ In fact, M4 can also be *nothing*. In other words, it may be optional. This is p 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. - + The worst-case withdrawal time obeys f(n)=3+(3/n) months, where n is the number of simultaneous withdrawals. @@ -453,12 +453,12 @@ As a soft fork, older software will continue to operate without modification. No This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" 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== -- cgit v1.2.3 From 68918ad24a568a302bf6e54932a38d3b73ec3d65 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:15:21 -0500 Subject: resync --- bip-blind-merged-mining.md | 329 ++++++++++++++++ bip-blind-merged-mining/bmm-dots-examples.png | Bin 0 -> 41116 bytes bip-blind-merged-mining/images.txt | 1 + bip-blind-merged-mining/witness-vs-critical.png | Bin 0 -> 67570 bytes bip-hashrate-escrows.mediawiki | 483 ------------------------ bip-hashrate-escrows/images.txt | 1 - bip-hashrate-escrows/two-groups.png | Bin 39695 -> 0 bytes 7 files changed, 330 insertions(+), 484 deletions(-) create mode 100644 bip-blind-merged-mining.md create mode 100644 bip-blind-merged-mining/bmm-dots-examples.png create mode 100644 bip-blind-merged-mining/images.txt create mode 100644 bip-blind-merged-mining/witness-vs-critical.png delete mode 100644 bip-hashrate-escrows.mediawiki delete mode 100644 bip-hashrate-escrows/images.txt delete mode 100644 bip-hashrate-escrows/two-groups.png 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 + CryptAxe + Chris Stewart + 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 Binary files /dev/null and b/bip-blind-merged-mining/bmm-dots-examples.png differ diff --git a/bip-blind-merged-mining/images.txt b/bip-blind-merged-mining/images.txt new file mode 100644 index 0000000..2fbbf63 --- /dev/null +++ b/bip-blind-merged-mining/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. 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 Binary files /dev/null and b/bip-blind-merged-mining/witness-vs-critical.png differ 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 @@ - - -
-    BIP: ????
-    Layer: Consensus (soft fork)
-    Title: Hashrate Escrows (Consensus layer)
-    Author: Paul Sztorc 
-            CryptAxe 
-    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
-
- -==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. - - - -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-escrow1, 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 great2. 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"2, 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 ===== - -1 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. - -2 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. - -
-// 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== - -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/images.txt b/bip-hashrate-escrows/images.txt deleted file mode 100644 index 2fbbf63..0000000 --- a/bip-hashrate-escrows/images.txt +++ /dev/null @@ -1 +0,0 @@ -Images used as reference in the documentation. diff --git a/bip-hashrate-escrows/two-groups.png b/bip-hashrate-escrows/two-groups.png deleted file mode 100644 index c8a3ffa..0000000 Binary files a/bip-hashrate-escrows/two-groups.png and /dev/null differ -- cgit v1.2.3 From 70f0ed6c39bec8d50ae29a2b2b562b44d84df5b7 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:23:31 -0500 Subject: switch to mediawiki format --- bip-blind-merged-mining.md | 329 ------------------------------------- bip-blind-merged-mining.mediawiki | 330 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 330 insertions(+), 329 deletions(-) delete mode 100644 bip-blind-merged-mining.md create mode 100644 bip-blind-merged-mining.mediawiki diff --git a/bip-blind-merged-mining.md b/bip-blind-merged-mining.md deleted file mode 100644 index f203e40..0000000 --- a/bip-blind-merged-mining.md +++ /dev/null @@ -1,329 +0,0 @@ - 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 - CryptAxe - Chris Stewart - 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.mediawiki b/bip-blind-merged-mining.mediawiki new file mode 100644 index 0000000..3aaf81b --- /dev/null +++ b/bip-blind-merged-mining.mediawiki @@ -0,0 +1,330 @@ + +
+
+    BIP: ????
+    Layer: Consensus (soft fork)
+    Title: Blind Merged Mining (Consensus layer)
+    Author: Paul Sztorc 
+            CryptAxe 
+            Chris Stewart 
+    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: + +# Track a set of ordered hashes (the merged-mining). +# 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: + +# 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). + +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). + + + +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: + +# If the critical data conditions are met, **Mary** can claim the outputs of the transaction with finality. +# 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: + +# The sidechain-block-generator "Simon" paying himself the side:block's side:tx-fees (which he receives in 100 sidechain blocks (blocks atop) hence). +# "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: + +# 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. +# 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). +# 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. + + + + + +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. -- cgit v1.2.3 From 5418516065646d35e81ee956a94244dbf81ab1c1 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:31:01 -0500 Subject: typos --- bip-blind-merged-mining.mediawiki | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 3aaf81b..9a919f8 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -194,12 +194,13 @@ M8_V1 does not require the Lightning network but does have new requirements for 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. @@ -225,17 +226,19 @@ Interestingly, these payments (M8) will *always* be directed to miners from non- ===== 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. +M8_V2 requires having a LN-channel pathway 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. -- cgit v1.2.3 From 17db87224d5e58aa29741cc0077f82ff07ab3803 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 17:31:54 -0500 Subject: move Chris CS indicated via tweet that he felt he did not contribute enough to be a co-author --- bip-blind-merged-mining.mediawiki | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 9a919f8..32ffa12 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -6,7 +6,6 @@ Title: Blind Merged Mining (Consensus layer) Author: Paul Sztorc CryptAxe - Chris Stewart Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-??????? Status: Draft @@ -325,7 +324,7 @@ Also, for interest, see an example sidechain here: https://github.com/drivechain ==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. +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== -- cgit v1.2.3 From 2a981366e7e81d6efb782ea675b7dbfa638cd24e Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Sat, 10 Feb 2018 18:26:52 -0500 Subject: clarifications + backward compatibility --- bip-blind-merged-mining.mediawiki | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 32ffa12..29a735c 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -19,7 +19,7 @@ ==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. +Blind Merged Mining (BMM) is a way of mining optional extension blocks, ie "asymmetric 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. @@ -54,10 +54,12 @@ As stated above, we have two goals: [1] create and monitor an alt-chain (defined 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) + 32-bytes - sideHeaderHash (also known as "h*" / hashCritical, the hash of the blockheader of the sidechain in question) + 2-bytes - prevBlockRef (an index which points to this side:blockheader's parent side:blockheader) -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. +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:blockheader 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. + +This data is "critical" in the sense that it is the minimum amount of data required to define a sidechain. Where does this data come from, and how does it get around? @@ -138,7 +140,7 @@ To efficiently keep track of the above data, without having to constantly load a 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. +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 LN connection with each main:miner. However, in the long run we expect the lightning version to be preferred. ==== Setup ==== @@ -292,6 +294,13 @@ Although, if Simon proceeds immediately, he removes the protection of the 'ratch 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). +==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== -- cgit v1.2.3 From 485b1318bd4a6f2e1378add714ce7af2cffee87b Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Mon, 23 Apr 2018 20:50:11 -0400 Subject: m7 op return update This has been right in the code, but I kept forgetting to update the BIP. --- bip-blind-merged-mining.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 29a735c..513a4b7 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -85,12 +85,12 @@ Mainchain nodes are going to need this data later, so it must be easy to find. W ==== M7 -- "Blind-Mine the Sidechain(s)" ==== -Thus, (for n sidechains) we have a coinbase output with: +Thus, (for n sidechains) we have a coinbase output with multiple OP_RETURNs (we've changed the tx-standardness policy to allow multiple OP_RETURNs): 1-byte - OP_RETURN (0x6a) - 1-byte - Push the following (4+(n*35)) bytes (0x??) + 1-byte - Push the following 39 bytes (0x27) 4-byte - Message header (0xD3407053) - (n*(32+5))-byte - A sequence of bytes, of the three Mini-Header items (h*, prevBlockRef, ChainIndex). + 37-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.) -- cgit v1.2.3 From c90088ed815ea243db7454b921461ea97113f006 Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Thu, 4 Apr 2019 16:22:09 -0700 Subject: improved image, with examples --- bip-blind-merged-mining/witness-vs-critical.png | Bin 67570 -> 265603 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/bip-blind-merged-mining/witness-vs-critical.png b/bip-blind-merged-mining/witness-vs-critical.png index 1a2458d..77003e8 100644 Binary files a/bip-blind-merged-mining/witness-vs-critical.png and b/bip-blind-merged-mining/witness-vs-critical.png differ -- cgit v1.2.3 From bbcab029ea0c4e6237087e76102e62df5e1d530d Mon Sep 17 00:00:00 2001 From: Paul Sztorc Date: Thu, 4 Apr 2019 16:26:19 -0700 Subject: number, shorten, clarify, link to working code --- bip-blind-merged-mining.mediawiki | 253 +++++++++++--------------------------- 1 file changed, 74 insertions(+), 179 deletions(-) diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 513a4b7..ffa883a 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -1,13 +1,13 @@ 
 
-    BIP: ????
+    BIP: 301
     Layer: Consensus (soft fork)
     Title: Blind Merged Mining (Consensus layer)
     Author: Paul Sztorc 
             CryptAxe 
     Comments-Summary: No comments yet.
-    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???????
+    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-301
     Status: Draft
     Type: Standards Track
     Created: 2017-10-24
@@ -19,16 +19,11 @@
 ==Abstract==
 
 
-Blind Merged Mining (BMM) is a way of mining optional extension blocks, ie "asymmetric 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.
+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. 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.
+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].
 
-To support BMM, the mainchain is asked to accomplish two goals:
-
-# Track a set of ordered hashes (the merged-mining).
-# 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).
+Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block.
 
 
 ==Motivation==
@@ -39,213 +34,94 @@ Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure
 # 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).
 
-Blind Merged-Mining (BMM) attempts to address those shortcomings.
+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.
-
-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 blockheader of the sidechain in question)
-    2-bytes  - prevBlockRef (an index which points to this side:blockheader's parent side:blockheader)
-
-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:blockheader 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.
-
-This data is "critical" in the sense that it is the minimum amount of data required to define a sidechain.
-
-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).
-
-
-
-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 =====
+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.
 
-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)" ====
+=== BMM Request ===
 
-Thus, (for n sidechains) we have a coinbase output with multiple OP_RETURNs (we've changed the tx-standardness policy to allow multiple OP_RETURNs):
+To buy the right to find a sidechain block, users broadcast BMM Requests.
 
-    1-byte - OP_RETURN (0x6a)
-    1-byte - Push the following 39 bytes (0x27)
-    4-byte - Message header (0xD3407053)
-    37-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.)
+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.
 
-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). 
+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)).
 
-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.
+==== Immediate Expiration ("Fill-or-Kill") ====
 
-We are left with, at most, one (h*, prevBlockRef) pair per sidechain per block. This data is added directly to D3, a new database.
+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).
 
-==== D3 -- "RecentSidechains_DB" ====
+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.
 
-To suit our purposes, the mainchain full nodes will need to keep track of the most recent 8000 (h\*, prevBlockRef) pairs.
+==== OnChain BMM Request ====
 
-( 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. )
+OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation.
 
-Therefore, D3 would look something like this:
+===== Structure =====
 
+The following data is required:
 
 
-           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
+    32-bytes  - h* sideHeaderHash
+    ?~?-bytes - critical data extended serialization
+        3-bytes - 0x00bf00 identifying bytes
+        1-byte  - nSidechain
+        2-bytes - prevSideBlockRef
+        4-bytes - prevMainHeaderBytes
 

 
+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.
 
-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 LN connection 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:
-
-# If the critical data conditions are met, **Mary** can claim the outputs of the transaction with finality.
-# If the critical data conditions are not met, the outputs become immediately available again to **Simon**.
-
-
-==== Goals (this is rather philosophical, and skippable) ====
+prevBlockRef, is a little more complicated (next section). 
 
-===== Immediate Expiration ("Fill-or-Kill") =====
+To qualify for inclusion in a block, BMM requests are subject to the following reqirements:
 
-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:
-
-# The sidechain-block-generator "Simon" paying himself the side:block's side:tx-fees (which he receives in 100 sidechain blocks (blocks atop) hence).
-# "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)
-

+# 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).
 
-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.
+===== prevBlockRef =====
 
-We do this by imposing validity-rules on the txn itself:
+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.
 
-# 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.
-# 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).
-# 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).
+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.
 
-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.
+===== 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).
 
 
 
+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].
 
-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. They never need to be rescanned.
 
-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 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).
 
-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).
+==== Lightning BMM Request ====
 
-===== M8_V2 With Lightning =====
+Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today.
 
-M8_V2 requires having a LN-channel pathway open with a miner. 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:
 
-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)
+
	
+    4-bytes - Message header (0xD0520C6E)	
+    1-byte - sidechain number
+    32-bytes  - h* side:block hash	
+    32-bytes  - prevSideBlockHash	
 

 
+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.
 
-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 side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*).
 
-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.
+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.
 
@@ -262,7 +138,7 @@ We start with (I):
 

 
 
-And both parties move, from there to "M8_V2" (II):
+And both parties move, from there to (II):
 
 
     Simon 13 in, Mary 40 in ; 53 in total
@@ -289,10 +165,28 @@ From here, if the h\* side:block in question is BMMed, they can proceed to (III)
             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 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 ouput 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==
 
@@ -310,14 +204,14 @@ This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and usi
 
 // 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.
+consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020.
+consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021.
 

 
 
 ==Reference Implementation==
 
-See: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
+See: https://github.com/DriveNetTESTDRIVE/DriveNet
 
 Also, for interest, see an example sidechain here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
 
@@ -339,3 +233,4 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam
 ==Copyright==
 
 This BIP is licensed under the BSD 2-clause license.
+
-- 
cgit v1.2.3


From 2d7093ba7682d6834cda1e8bf79db8ce1794bf37 Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Fri, 5 Apr 2019 10:02:24 -0700
Subject: spellcheck

---
 bip-blind-merged-mining.mediawiki | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki
index ffa883a..7f29f06 100644
--- a/bip-blind-merged-mining.mediawiki
+++ b/bip-blind-merged-mining.mediawiki
@@ -1,4 +1,3 @@
-
 
 
     BIP: 301
@@ -49,7 +48,7 @@ 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)).
+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") ====
 
@@ -78,7 +77,7 @@ sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The
 
 prevBlockRef, is a little more complicated (next section). 
 
-To qualify for inclusion in a block, BMM requests are subject to the following reqirements:
+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.
@@ -94,7 +93,7 @@ Above: Three blockchains, with different max length (small number), reorganizati
 
 ===== 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).
+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).
 
 
 
@@ -110,11 +109,11 @@ Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. Th
 
 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:
 
-
	
-    4-bytes - Message header (0xD0520C6E)	
+
   
+    4-bytes - Message header (0xD0520C6E)   
     1-byte - sidechain number
-    32-bytes  - h* side:block hash	
-    32-bytes  - prevSideBlockHash	
+    32-bytes  - h* side:block hash  
+    32-bytes  - prevSideBlockHash   
 

 
 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.
@@ -173,7 +172,7 @@ 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 ouput into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)
+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)
@@ -233,4 +232,3 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam
 ==Copyright==
 
 This BIP is licensed under the BSD 2-clause license.
-
-- 
cgit v1.2.3


From d69e368ce3ef402e57f34ed40bf61508355ffa9d Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Wed, 17 Apr 2019 16:59:40 -0700
Subject: typo

the critical txn should start with "03", as it has version number 3
---
 bip-blind-merged-mining/witness-vs-critical.png | Bin 265603 -> 268309 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/bip-blind-merged-mining/witness-vs-critical.png b/bip-blind-merged-mining/witness-vs-critical.png
index 77003e8..79c84b1 100644
Binary files a/bip-blind-merged-mining/witness-vs-critical.png and b/bip-blind-merged-mining/witness-vs-critical.png differ
-- 
cgit v1.2.3


From 329df0b8368e04c92780cb039f1c5fb9f0cd386c Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:14:33 -0700
Subject: Update dates/links to merge

---
 bip-blind-merged-mining.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki
index 7f29f06..1a6e999 100644
--- a/bip-blind-merged-mining.mediawiki
+++ b/bip-blind-merged-mining.mediawiki
@@ -9,7 +9,7 @@
     Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-301
     Status: Draft
     Type: Standards Track
-    Created: 2017-10-24
+    Created: 2019-07-23
     License: BSD-2-Clause
 
 

@@ -87,7 +87,7 @@ To qualify for inclusion in a block, BMM requests are subject to the following r
 
 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.
 
-
+
 
 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.
 
@@ -95,7 +95,7 @@ Above: Three blockchains, with different max length (small number), reorganizati
 
 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).
 
-
+
 
 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].
 
-- 
cgit v1.2.3


From 6ca33dc63512a47f80321e2ae0222d5532571d7e Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:18:18 -0700
Subject: Rename bip-blind-merged-mining.mediawiki to bip-0301.mediawiki

---
 bip-0301.mediawiki                | 234 ++++++++++++++++++++++++++++++++++++++
 bip-blind-merged-mining.mediawiki | 234 --------------------------------------
 2 files changed, 234 insertions(+), 234 deletions(-)
 create mode 100644 bip-0301.mediawiki
 delete mode 100644 bip-blind-merged-mining.mediawiki

diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki
new file mode 100644
index 0000000..1a6e999
--- /dev/null
+++ b/bip-0301.mediawiki
@@ -0,0 +1,234 @@
+
+
+    BIP: 301
+    Layer: Consensus (soft fork)
+    Title: Blind Merged Mining (Consensus layer)
+    Author: Paul Sztorc 
+            CryptAxe 
+    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
+
+

+
+
+==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:
+
+
+    32-bytes  - h* sideHeaderHash
+    ?~?-bytes - critical data extended serialization
+        3-bytes - 0x00bf00 identifying bytes
+        1-byte  - nSidechain
+        2-bytes - prevSideBlockRef
+        4-bytes - prevMainHeaderBytes
+

+
+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.
+
+
+
+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).
+
+
+
+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:
+
+
   
+    4-bytes - Message header (0xD0520C6E)   
+    1-byte - sidechain number
+    32-bytes  - h* side:block hash  
+    32-bytes  - prevSideBlockHash   
+

+
+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):
+
+
+    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 (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
+

+
+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.
+
+
+// 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.
+

+
+
+==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.
diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki
deleted file mode 100644
index 1a6e999..0000000
--- a/bip-blind-merged-mining.mediawiki
+++ /dev/null
@@ -1,234 +0,0 @@
-
-
-    BIP: 301
-    Layer: Consensus (soft fork)
-    Title: Blind Merged Mining (Consensus layer)
-    Author: Paul Sztorc 
-            CryptAxe 
-    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
-
-

-
-
-==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:
-
-
-    32-bytes  - h* sideHeaderHash
-    ?~?-bytes - critical data extended serialization
-        3-bytes - 0x00bf00 identifying bytes
-        1-byte  - nSidechain
-        2-bytes - prevSideBlockRef
-        4-bytes - prevMainHeaderBytes
-

-
-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.
-
-
-
-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).
-
-
-
-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:
-
-
   
-    4-bytes - Message header (0xD0520C6E)   
-    1-byte - sidechain number
-    32-bytes  - h* side:block hash  
-    32-bytes  - prevSideBlockHash   
-

-
-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):
-
-
-    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 (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
-

-
-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.
-
-
-// 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.
-

-
-
-==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.
-- 
cgit v1.2.3


From 1ff5d5d8253191bead9ffc3924c668292747777b Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:20:44 -0700
Subject: rename folder

---
 bip-0301/images.txt                | 1 +
 bip-blind-merged-mining/images.txt | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 bip-0301/images.txt
 delete mode 100644 bip-blind-merged-mining/images.txt

diff --git a/bip-0301/images.txt b/bip-0301/images.txt
new file mode 100644
index 0000000..2fbbf63
--- /dev/null
+++ b/bip-0301/images.txt
@@ -0,0 +1 @@
+Images used as reference in the documentation.
diff --git a/bip-blind-merged-mining/images.txt b/bip-blind-merged-mining/images.txt
deleted file mode 100644
index 2fbbf63..0000000
--- a/bip-blind-merged-mining/images.txt
+++ /dev/null
@@ -1 +0,0 @@
-Images used as reference in the documentation.
-- 
cgit v1.2.3


From 42e96858d5e13793abbf9820ed38720d64783cda Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:26:15 -0700
Subject: move images

---
 bip-0301/bmm-dots-examples.png   | Bin 0 -> 41116 bytes
 bip-0301/witness-vs-critical.png | Bin 0 -> 268309 bytes
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bip-0301/bmm-dots-examples.png
 create mode 100644 bip-0301/witness-vs-critical.png

diff --git a/bip-0301/bmm-dots-examples.png b/bip-0301/bmm-dots-examples.png
new file mode 100644
index 0000000..70f11f6
Binary files /dev/null and b/bip-0301/bmm-dots-examples.png differ
diff --git a/bip-0301/witness-vs-critical.png b/bip-0301/witness-vs-critical.png
new file mode 100644
index 0000000..79c84b1
Binary files /dev/null and b/bip-0301/witness-vs-critical.png differ
-- 
cgit v1.2.3


From 69670c9da20ac696ad696ba07e58093796a8c5bb Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:26:45 -0700
Subject: cleanup 1

---
 bip-blind-merged-mining/bmm-dots-examples.png | Bin 41116 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 bip-blind-merged-mining/bmm-dots-examples.png

diff --git a/bip-blind-merged-mining/bmm-dots-examples.png b/bip-blind-merged-mining/bmm-dots-examples.png
deleted file mode 100644
index 70f11f6..0000000
Binary files a/bip-blind-merged-mining/bmm-dots-examples.png and /dev/null differ
-- 
cgit v1.2.3


From 4cd4e53752496e155243693fffbf79c7ed2daa9d Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Tue, 23 Jul 2019 09:26:54 -0700
Subject: cleanup 2

---
 bip-blind-merged-mining/witness-vs-critical.png | Bin 268309 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 bip-blind-merged-mining/witness-vs-critical.png

diff --git a/bip-blind-merged-mining/witness-vs-critical.png b/bip-blind-merged-mining/witness-vs-critical.png
deleted file mode 100644
index 79c84b1..0000000
Binary files a/bip-blind-merged-mining/witness-vs-critical.png and /dev/null differ
-- 
cgit v1.2.3


From db117ef473492c180939e694773104002a3929a4 Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Thu, 25 Jul 2019 23:51:05 -0700
Subject: fix spacing

---
 bip-0301.mediawiki | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki
index 1a6e999..3b77f58 100644
--- a/bip-0301.mediawiki
+++ b/bip-0301.mediawiki
@@ -1,5 +1,4 @@
 
-
     BIP: 301
     Layer: Consensus (soft fork)
     Title: Blind Merged Mining (Consensus layer)
@@ -11,10 +10,8 @@
     Type: Standards Track
     Created: 2019-07-23
     License: BSD-2-Clause
-
 

 
-
 ==Abstract==
 
 
@@ -27,7 +24,6 @@ Our goal here, is to allow mainchain miners to trustlessly "sell" the act of fin
 
 ==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.)
@@ -38,7 +34,6 @@ 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.
 
 
@@ -194,8 +189,6 @@ As a soft fork, older software will continue to operate without modification. As
 (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.
@@ -217,7 +210,6 @@ Also, for interest, see an example sidechain here: https://github.com/drivechain
 
 ==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
-- 
cgit v1.2.3


From 542c66e6ddc3d9f703114f7e645f19d572c8274e Mon Sep 17 00:00:00 2001
From: Paul Sztorc 
Date: Thu, 25 Jul 2019 23:57:12 -0700
Subject: Add 301 Blind Merged Mining

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index bcc1e3f..956dad8 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -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
 |}
 
 
-- 
cgit v1.2.3


From 53e37a1dea527c51c9bacb02975cd3184d873742 Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Fri, 26 Jul 2019 12:41:03 +0000
Subject: Fix preamble in BIP 301

---
 bip-0301.mediawiki | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki
index 3b77f58..d6056f2 100644
--- a/bip-0301.mediawiki
+++ b/bip-0301.mediawiki
@@ -1,15 +1,15 @@
 
-    BIP: 301
-    Layer: Consensus (soft fork)
-    Title: Blind Merged Mining (Consensus layer)
-    Author: Paul Sztorc 
-            CryptAxe 
-    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
+  BIP: 301
+  Layer: Consensus (soft fork)
+  Title: Blind Merged Mining (Consensus layer)
+  Author: Paul Sztorc 
+          CryptAxe 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0301
+  Status: Draft
+  Type: Standards Track
+  Created: 2019-07-23
+  License: BSD-2-Clause
 

 
 ==Abstract==
-- 
cgit v1.2.3