highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-04-04 18:20:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1227 from psztorc/master

Browse Source 
Update BIPs 300/301
This commit is contained in:
Luke Dashjr 2021-12-15 21:56:14 +00:00 committed by GitHub
commit 63c2a61775
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 271 additions and 317 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

280
bip-0300.mediawiki
View File

@ -15,143 +15,181 @@
==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 the 2014 Blockstream whitepaper].
In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by the accumulation of hashpower over time.
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 the accumulation of hashpower over time.
Bip300 emphasizes slow, transparent, auditable transactions which are easy for honest users to get right and very hard for dishonest users to abuse. The chief design goal for Bip300 is ''partitioning'' -- users may safely ignore Bip300 txns if they want to (or Bip300 entirely).
This project has [http://www.drivechain.info/ a website] which includes [http://www.drivechain.info/faq/index.html an FAQ].
See [http://www.drivechain.info/ this site] for more information.
==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:
As Reid Hoffman [https://blockstream.com/2015/01/13/en-reid-hoffman-on-the-future-of-the-bitcoin-ecosystem/ wrote in 2014]: "Sidechains allow developers to add features and functionality to the Bitcoin universe without actually modifying the Bitcoin Core code...Consequently, innovation can occur faster, in more flexible and distributed ways, without losing the synergies of a common platform with a single currency."
# Protect Bitcoin from competition from altcoins and spinoffs.
# Protect Bitcoin from hard fork campaigns. (Such campaigns represent an existential threat to Bitcoin, as well as an avenue for developer corruption.)
# Help with review, by making it much easier for reviewers to ignore bad ideas.
# Provide an avenue for good-but-confusing ideas to prove their value safely.
Coins such as Namecoin, Monero, ZCash, and Sia, offer features that Bitcoiners cannot access -- not without selling their BTC to invest in a rival monetary unit. According to [https://coinmarketcap.com/charts/#dominance-percentage coinmarketcap.com], there is now more value *outside* the BTC protocol than within it. According to [https://cryptofees.info/ cryptofees.info], 10x more txn fees are paid outside the BTC protocol, than within it.
Software improvements to Bitcoin rely on developer consensus -- BTC will pass on a good idea if it is even slightly controversial. Development is slow: we are now averaging one major feature every 5 years.
Sidechains allow for competitive "benevolent dictators" to create a new sidechain at any time. These dictators are accountable only to their users, and (crucially) they are protected from rival dictators. Users can move their BTC among these different pieces of software, as *they* see fit.
BTC can copy every useful technology, as soon as it is invented; scamcoins lose their justification and become obsolete; and the community can be pro-creativity, knowing that Layer1 is protected from harmful changes.
==Specification==
==== Components ====
Bip300 allows for six new blockchain messages:
Hashrate Escrows are built of two types of component: [1] new databases, and [2] new message-interpretations.
* M1. "Propose New Sidechain"
* M2. "ACK Proposal"
* M3. "Propose Bundle"
* M4. "ACK Bundle"
* M5. Deposit -- a transfer of BTC from-main-to-side
* M6. Withdrawal -- a transfer of BTC from-side-to-main
===== 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
Nodes organize those messages into two caches:
* D1. "Escrow_DB" -- tracks the 256 Hashrate Escrows (Escrows slots that a sidechain can live in).
* D2. "Withdrawal_DB" -- tracks the withdrawal-Bundles (coins leaving a Sidechain).
We will cover:
# Adding Sidechains (D1, M1, M2)
# Approving Withdrawals (D2, M3, M4)
# Depositing and Withdrawing (M5, M6)
=== Adding Sidechains (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.
The table below enumerates the new database fields, their size in bytes, and their purpose. A sidechain designer is free to choose any value for these.
{| class="wikitable"
|- style="font-weight:bold; text-align:center; vertical-align:middle;"
! Field No.
! Label
! Type
! Description / Purpose
|-
|- style="vertical-align:middle;"
| 1
| Escrow Number
| uint8_t
| A number assigned to the entire escrow. Used to make it easy to refer to each escrow.
| The escrow's ID number. Used to uniquely refer to each sidechain.
|-
| 2
| Sidechain Deposit Script Hex
| string
| The script that will be deposited to, and update the CTIP of the sidechain.
| Version
| int32_t
| Version number.
|-
| 3
| String KeyID
| string
| Used to derive all sidechain deposit addresses.
|-
| 4<br />
| Sidechain Private Key
| string
| The private key of the sidechain deposit script.
|-
| 4
| Escrow Name
|- style="vertical-align:middle;"
| 5<br />
| ScriptPubKey
| CScript
| Where the sidechain coins go. This always stays the same, even though the CTIP (UTXO) containing the coins is always changing.
|- style="vertical-align:middle;"
| 6
| Sidechain Name
| string
| A human-readable name of the sidechain.
|-
| 5
| Escrow Description
| string
| A human-readable name description of the sidechain. More than enough space to hold a 32 byte hash.
|-
| 6
| Hash ID 1
| uint256
| A field of 32 bytes, which could be any bytes such as a sha256 hash.
|-
|- style="vertical-align:middle;"
| 7
| Hash ID 2
| uint256
| A field of 32 bytes, which could be any bytes such as a sha256 hash.
|-
| Sidechain Description
| string
| A human-readable name description of the sidechain.
|- style="vertical-align:middle;"
| 8
| Hash1 - tarball hash
| uint256
| Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced anywhere by Bip300, and is for human purposes only.)
|- style="vertical-align:middle;"
| 9
| Hash2 - git commit hash
| uint160
| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced anywhere by Bip300, and is for human purposes only.)
|-
| 10
| Active
| bool
| Does this sidechain slot contain an active sidechain?<br />
|- style="vertical-align:middle;"
| 11
| "CTIP" -- Part 1 "TxID"
| uint256
| 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).
|-
| 9
| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the sidechain's money is (ie, which member of the UTXO set).
|- style="vertical-align:middle;"
| 12
| "CTIP" -- Part 2 "Index"
| int32_t
| Of the CTIP, this is second element of the pair: the Index. See #9 above.
|-
| Of the CTIP, the second element of the pair: the Index. See #11 above.
|}
D1 is updated via M1 and M2.
( The following messages were modeled on SegWit -- see [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure here] and [https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3348-L3375 here]. )
==== M1 -- "Propose New Sidechain" ====
1-byte - OP_RETURN (0x6a)
4-byte - Commitment header (0xD5E0C4AF)
N-byte - The serialization of the sidechain.
Examples:
<img src="bip-0300/m1-gui.jpg?raw=true" align="middle"></img>
<img src="bip-0300/m1-cli.png?raw=true" align="middle"></img>
M1 is a coinbase OP Return output containing the following:
1-byte - OP_RETURN (0x6a)
4-byte - Message header (0xD5E0C4AF)
N-byte - The serialization of the sidechain.
1-byte nSidechain
4-byte nVersion
x-byte strKeyID
x-byte strPrivKey
x-byte scriptPubKey
x-byte title
x-byte description
32-byte hashID1
20-byte hashID2
M1 is used in conjunction with M2.
==== M2 -- "ACK Sidechain Proposal" ====
1-byte - OP_RETURN (0x6a)
4-byte - Commitment header (0xD6E1C5BF)
32-byte - Commitment hash: sha256D hash of sidechain's serialization
4-byte - Message header (0xD6E1C5BF)
32-byte - sha256D hash of sidechain's serialization
==== New Block Validation Rules ====
==== M1/M2 Validation Rules ====
# Any miner can propose a new sidechain at any time. This procedure resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 90% of the following 2016 blocks.
# It is possible to "overwrite" a sidechain. This requires more ACKs -- 50% of the following 26300 blocks must contain an M2. The possibility of overwrite, does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26300 blocks).
# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 95% of the following 2016 blocks.
# It is possible to "overwrite" an escrow. This requires 6 months (26298 blocks) of M2s, instead of 2 weeks (XXXX). This possibility does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26298 blocks).
=== Approving Withdrawals (D2, M3, M4) ===
Withdrawals in Bip300 (ie, "M6"), are very significant. So, we will first discuss how these are approved/rejected -- a process involving M3, M4, and D2.
==== What are Bundles? ====
All Bip300 withdrawals take the form of “Bundles” (formerly known as “WT^s”) -- named because they "bundle up" many individual withdrawal-requests into one single rare layer1 transaction.
This bundle either pays all of the withdrawals out, or else it fails (and pays nothing out). Bip300 / layer 1 does not assemble Bundles (the sidechain developer does this in a manner of their choosing).
Bundles are identified by a 32-byte hash, which aspires to be the TxID of M6. Unfortunately, the Bundle-hash and M6-TxID cannot match exactly, since the first input to M6 is a CTIP which is constantly changing. So, we must accomplish a task, which is conceptually similar to AnyPrevOut (BIP 118). We define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. In our case, these bytes are the first input and the first output.
D2 controls Bundles, and is driven by M3, M4, M5, and M6.
=== Withdrawing from Escrows (D2, M3, M4) ===
==== D2 -- "Withdrawal_DB" ====
D2 changes deterministically with respect to M3, M4, M5, and M6.
{| class="wikitable"
! Field No.
@ -160,117 +198,108 @@ D2 changes deterministically with respect to M3, M4, M5, and M6.
! Description / Purpose
|-
| 1
| Escrow Number
| Sidechain Number
| uint8_t
| Links the withdrawal-request to a specific escrow.
| Links the withdrawal-request to a specific hashrate escrow.
|-
| 2
| WT^ Hash
| Bundle Hash
| uint256
| 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.
| A withdrawal attempt. Specifically, it is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a txn which could withdraw funds from a sidechain.
|-
| 3
| ACKs (Work Score)
| uint16_t
| The current total number of ACKs (PoW)
| The current total number of ACKs (the PoW that has been used to validate the Bundle).
|-
| 4
| Blocks Remaining (Age)
| uint16_t
| The number of blocks which this WT^ has remaining to accumulate ACKs
| The number of blocks which this Bundle has remaining to accumulate ACKs
|}
A hash of D2 exists in each coinbase txn, and has consensus-significance.
==== New Block Validation Rules for D2 ====
==== D2 Validation Rules ====
# A hash commitment to D2 exists in each block (even if D2 is blank).
# Withdrawals in D2 are sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort.
# From one block to the next, "Age" fields must increase by exactly 1.
# Withdrawals are stored in D2 until they fail ("Age" = "MaxAge"), or they succeed (the blockchain contains a txn whose blinded txID matches "WT^").
# The D2 hash commitment must be in each block (unless D2 is blank).
# The Bundles must be listed in a canonical order (so that the hashes match).
# From one block to the next, "Age" fields must increase by exactly 1 (ie, Blocks Remaining decreases by 1).
# Bundles are stored in D2 until they fail (which occurs at "Age" = "MaxAge"), or they succeed (Bundle is paid out).
# From one block to the next, the value in the ACKs field can increase or decrease by a maximum of 1 (see below).
In addition, there are special rules for the "ACKs" field (see M4 below).
If a Bundle succeeds (in D2), it "becomes" an M6 message and is included in a block.
==== M3 -- "Propose Withdrawal" ====
So, first: how do we add a Bundle to D2?
==== M3 -- "Propose Bundle" ====
Nodes will add an entry to D2 if there is a coinbase output with the following:
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xD45AA943)
32-byte - The WT^ hash to populate a new D2 entry
32-byte - The Bundle hash, to populate a new D2 entry
==== New Block Validation Rules for M3 ====
==== M3 Validation Rules ====
# 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.
# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting Blocks Remaining value is 26,299. The starting ACKs count is 1.
# Each block can only contain one M3 per sidechain.
Once a Bundle is in D2, how can we give it enough ACKs to make it valid?
==== M4 -- "ACK Withdrawal" ====
M4 is a way of describing changes to the "ACKs" column of D2.
From one block to the next, "ACKs" can only change as follows:
* The ACK-counter of any withdrawal can only change by (-1,0,+1).
* Within a sidechain-group, upvoting one withdrawal ("+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).
* While only one withdrawal can be upvoted at once, they can all be unchanged at once ("abstain") and they can all be downvoted at once ("alarm").
* The ACK-counter of any Bundle can only change by (-1,0,+1).
* Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-value is zero.
* While only one Bundle can be upvoted at once; the whole group can all be unchanged at once ("abstain"), and they can all be downvoted at once ("alarm").
One option for explicit transmission of M4 is:
M4 does not need to be explicitly transmitted. It can simply be inferred from the new state of D2. M4 can therefore be improved over time, without affecting consensus.
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.
N-byte - stream of bits (not bytes), with a 1 indicating the position of the chosen action [downvote all, abstain, upvote1, upvote2, ...]
Nonetheless, one option for explicit transmission of M4 is [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3735-L3790 in our code].
But sometimes M4 does not need to be transmitted at all! If there are n Escrows and m Withdrawals-per-escrow, then there are (m+2)^n total candidates for the next D2. So, when m and n are low, all of the possible D2s can be trivially computed in advance.
Often, M4 does not need to be transmitted at all. If there are n Sidechains and m Withdrawals-per-sidechain, then there are (m+2)^n total candidates for the next D2. So, when m and n are low, all of the possible D2s can be trivially computed in advance.
Miners can impose a "soft limit" on m, blocking new withdrawal-attempts until previous ones expire. For a worst-case scenario of n=200 and m=1,000, honest nodes can communicate M4 with ~25 KB per block [4+1+1+(200\*(1000+1+1)/8)].
Miners can impose a "soft limit" on m, blocking new withdrawal-attempts until previous ones expire. Even if they fail to do this, a a worst-case scenario of n=200 and m=1,000, honest nodes can communicate the M4 with ~25 KB per block [4+1+1+(200\*(1000+1+1)/8)].
Finally, we give Deposits and Withdrawals.
=== Deposits and Withdrawals (M5, M6) ===
Both M5 and M6 are regular Bitcoin txns. They are identified, as Deposits/Withdrawals, when they select one of the special CTIP UTXOs as one of their inputs (see D1).
=== Depositing and Withdrawing (M5, M6) ===
All of a sidechain’s coins, are stored in one UTXO. (Deposits/Withdrawals never cause UTXO bloat.) So, each Deposit/Withdrawal must select a CTIP, and generate a new CTIP (this is tracked in D1, above).
Both M5 and M6 are regular Bitcoin txns. They are identified by meeting an important criteria: they select a one of the Critical TxID-index Pairs (a "CTIP") as one of their inputs.
Just as these txns must select a CTIP input, they must create a new CTIP output. D1 is then updated to match only the latest CTIP output. 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.
Deposits ("M5") are distinguished from withdrawals ("M6") by simply checking to see if money is "going in", or "out".
https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L647-L742
If the from-CTIP-to-CTIP quantity of coins goes '''up''', (ie, if the user is adding coins), then the txn is treated as a Deposit (M5). Else it is treated as a Withdrawal (M6). See [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L668-L781 here].
==== M5. "Make a Deposit" -- a transfer of BTC from-main-to-side ====
As far as mainchain consensus is concerned, deposits to the escrow are always valid.
However, in practice there will be additional requirements. The escrow account (ie the "sidechain") needs to know how to credit depositors. One well-known 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.
As far as mainchain consensus is concerned, all deposits to a sidechain are always valid.
==== 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.
We come, finally, to the critical matter: where users can take their money *out* of the sidechain.
In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
In each block, a Bundle in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transaction (the txn that actually withdraws funds from the escrow). The two cannot match exactly, because "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).
To solve this, we define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. Specifically, these bytes are the first input and the first output.
The Bundle must meet all these criteria:
So, withdrawals must meet the following three criteria:
# "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.
# "Be ACKed" -- The "blinded TxID" of this txn must be a member of the "approved candidate" set in the D2 of this block.
# "Return Change to Account" -- TxOut0 must pay coins back to the sidechain's CTIP.
# "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible.
==Backward compatibility==
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving the UTXO in single, infrequent bursts. However, these phenomena don't affect them, or the validity of the money that they receive.
( As a 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. )
( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that a sidechain's Bundles will continue to match identically, is to upgrade sidechains via soft forks of themselves. )
==Deployment==
@ -281,10 +310,9 @@ This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" and us
<pre>
// Deployment of Drivechains (BIPX, BIPY)
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1642276800; // January 15th, 2022.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1673812800; // January 15th, 2023.
</pre>
==Reference Implementation==

45
bip-0300/appendix-1.txt
View File

@ -1,45 +0,0 @@
==== Two Withdrawals at Once ====
Currently, the documentation and code describe a situation where only one withdrawal can proceed at a time. As a result, one "train" (carrying everyone's withdrawals) leaves the station every 3 months, and takes 3-6 months to reach its destination.
Thus, if a withdrawing-user is very unlucky, and "just misses" the train, this user must wait double-long. First, (s)he must wait for the missed-train to reach its destination. Second, (s)he must board the new train, and wait for *it* to reach its destination. Each of these steps takes 3-6 months.
So, even when withdrawals always go as quickly as possible (3 months each), the total time varies, from 3 months (0 months waiting + 3 months travel) to 6 months (3 months waiting + 3 months travel). The average is 4.5 months.
To improve this, we allow for slightly different behavior if the highest-ACK-withdrawal [1st] has an ACK score >= 6575; and [2nd] is not tied with any other withdrawal.
Basically: a second train can leave, if the furthest train is 50+% of the way to its destination.
So, previously, for m trains, M4 could be any of the following:
abstain
alarm (move all trains backwards)
move train #1 forward (and others backwards)
move train #2 forward (and others backwards)
...
move train #3 forward (and others backwards)
If our new special conditions apply, we now double the (m-1) elements, to accommodate a second train:
|abstain
|alarm (move all trains backwards)
|advance furthest train + advance train #1 (regress all others)
|advance furthest train + advance train #2 (regress all others)
|...
|advance furthest train + advance train #(m-1) (regress all others)
|regress furthest train + advance train #1 (regress all others)
|regress furthest train + advance train #2 (regress all others)
|...
|regress furthest train + advance train #(m-1) (regress all others)
It is theoretically possible (but in practice probably impossible) to troll this rule, by getting two (or even three) withdrawals to have >6575 ACK scores, and then getting these to *tie* for first place. Then they'd both be furthest. Hence the second condition prohibiting this new behavior, if the furthest trains have any ACK-score ties.
This simple change, which has almost zero impact on the security assumptions, improves the monthly total wait times drastically:
Worst-case: 6 --> 4.5
Average: 4.5 --> 3.75
Std Dev: ~.91 --> ~.45

BIN
bip-0300/m1-cli.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 161 KiB

BIN
bip-0300/m1-gui.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
bip-0300/two-groups.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

263
bip-0301.mediawiki
View File

@ -12,181 +12,151 @@
License: BSD-2-Clause
</pre>
==Abstract==
Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind").
Blind Merged Mining (BMM) 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.
Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners.
==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:
"Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin).
# 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).
However, traditional MM has two drawbacks:
# Miners must run a full node of the other chain(s). (Thus, they must run "non-Bitcoin" software which may be buggy.)
# Miners are paid on the other chain, in Alt-currency. (Miners who MM Namecoin, will earn NMC.)
==Notation and Example==
Note: We use notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to sort the mainchain version from its sidechain counterpart. We name all sidechain users "Simon", and name all mainchain miners "Mary".
Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.10 fee; therefore, the block is worth $2000 of fee-revenue. As usual: the sidechain's coinbase txn will pay this $2000 to someone (in this case, "Simon"). Under Bip301, Simon does no hashing, but instead makes one layer1 txn paying $1999 to the layer1 miners ("Mary").
{| class="wikitable"
|-
! colspan="3" | Upon finding a sidechain block worth $2000...
|- style="font-weight:bold; text-decoration:underline;"
| Item
| Layer1 Miner ("Mary")
| Sidechain User ("Simon")
|-
| Runs a sidechain node?
| No
| Yes
|-
| How much hashing?
| 100%
| 0%
|-
| Coins collected, on Layer2
| $0
| $2000
|-
| Coins paid out, on Layer1
| $0
| $1999
|-
| Coins rec'd, on Layer1
| $1999
| $0
|-
| d(Net Worth)
| +$1999
| +$1
|}
Bip301 makes this specialization-of-labor trustless on layer1. If Mary takes Simon's money, then she must let Simon control the side:block.
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.
Bip300 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*".
So we will discuss:
# h* -- The sidechain's hashMerkleRoot, and why it matters.
# "BMM Accept" -- How h* enters a main:coinbase. When Mary "accepts" a BMM Request, Mary is ''endorsing a side:block''.
# "BMM Request" -- Simon offering money to Mary, if (and only if) she will Endorse a specific h*. When Simon broadcasts a BMM Request, Simon is ''attempting a side:block''.
=== h* ===
h* ("h star") is the sidechain's Merkle Root hash.
In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important.
Note: in Bip301 sidechains, "headers" and "block hashes" do not have significant consensus meaning and are in the design mainly to help with IBD. (In the mainchain, in contrast, headers and block hashes determine the difficulty adjustments and cumulative PoW.)
<img src="bip-0301/sidechain-headers.png?raw=true" align="middle"></img>
Above: h* is located in the main:coinbase. h* contains all side:txns, including the side:coinbase. The side:coinbase contains many "header-like" fields, such as the hash of the previous side:block.
Mary controls the main:coinbase, so she may select any h*. Her selection will determine which side:block is "found".
=== BMM Accept ===
To "Accept" the BMM proposal (and to accept Simon's money), Mary must endorse Simon's block.
<pre>
For each side:block Mary wishes to endorse, Mary places the following into a main:coinbase OP_RETURN:
1-byte - OP_RETURN (0x6a)
4-bytes - Message header (0xD1617368)
32-bytes - h* (obtained from Simon)
</pre>
[https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3530-L3572 Code details here].
If these OP_RETURN outputs are not present, then no Requests were accepted. (And, Mary would get no money from Requests.)
It is possible for Mary and Simon to be the same person.They would trust each other completely, so the BMM process would stop here. There would only be Accepts; Requests would be unnecessary.
When Simon and Mary are different people, Simon will need to use BMM Requests.
=== 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:
Simon will use BMM Requests to buy the right to find a sidechain block, from Mary.
<pre>
32-bytes - h* sideHeaderHash
?~?-bytes - critical data extended serialization
3-bytes - 0x00bf00 identifying bytes
1-byte - nSidechain
2-bytes - prevSideBlockRef
4-bytes - prevMainHeaderBytes
For each side:block that Simon wants to attempt, he broadcasts a txn containing the following:
3-bytes - Message header (0x00bf00)
32-bytes - h* (side:MerkleRoot)
1-byte - nSidechain (sidechain ID number)
4-bytes - prevMainHeaderBytes (the last four bytes of the previous main:block)
</pre>
sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally.
prevBlockRef, is a little more complicated (next section).
To qualify for inclusion in a block, BMM requests are subject to the following requirements:
# Requests must match a corresponding "BMM Accept" (see last section of BIP).
# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include.
# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
===== prevBlockRef =====
prevBlockRef is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain blocks). If a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N; in the block after that it will be back to zero.
<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img>
Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other.
===== Extended Serialization =====
To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).
<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img>
Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here].
These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned.
Interestingly, these payments will *always* be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks).
==== Lightning BMM Request ====
Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today.
LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data:
<pre>
4-bytes - Message header (0xD0520C6E)
1-byte - sidechain number
32-bytes - h* side:block hash
32-bytes - prevSideBlockHash
</pre>
Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything.
Therefore, Simon will need to ensure that he '''gives each Mary a different h\*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*).
With a unique h\* per Mary (or, more precisely, per channel), and at most 1 h\* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time.
That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary.
We start with (I):
<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
13 ; to Simon if TimeLock=over; OR to Mary if SimonSig
40 ; to Mary
Mary's version [signed by Simon]
40 ; to me if TimeLock=over; OR to Simon if MarySig
13 ; to Simon
</pre>
We make use of the [https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/primitives/transaction.h#L224-L331 extended serialization format]. (SegWit used ESF to position scriptWitness data within txns; we use it here to position the five fields above.)
And both parties move, from there to (II):
The Message header identifies this txn as a BMM transaction. h* is chosen by Simon to correspond to his side:block. nSidechain is the number assigned to the sidechain when it was created. preSideBlockRef allows Simon to build on any preexisting side:block (allowing him to bypass one or more invalid blocks, details below). prevMainHeaderBytes are the last four bytes of the previous main:block (details below).
<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
40 ; to Mary
7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over
Mary's version [signed by Simon]
40 ; to Mary if TimeLock=over; OR to Simon if MarySig
6 ; to Simon
7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over
</pre>
This txn is invalid if it fails any of the following checks:
# Each "BMM Request", must match one corresponding "BMM Accept" (previous section).
# Only one BMM Request is allowed in each main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner singles out one BMM Request to include.
# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).
From here, if the h\* side:block in question is BMMed, they can proceed to (III):
<pre>
Simon 13 in, Mary 40 in ; 53 in total
Simon's version [signed by Mary]
6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
47 ; to Mary
Mary's version [signed by Simon]
47 ; to me if TimeLock=over; OR to Simon if MarySig
6 ; to Simon
</pre>
If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it.
If the h\* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h\*, trying again with new side:block in the next main:block).
Now that we have described Requests, we can describe how they are accepted.
=== BMM Accept ===
For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)
The following data is required in the "accept" OP_RETURN output:
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-bytes - Message header (0xD3407053)
32-bytes - h*
~5-bytes - BMM identifier bytes
[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code].
If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.)
Most BMM Request txns will never make it into a block. Simon will make many BMM Requests, but only one will be accepted. Since only one BMM Request can become a bona fide transaction, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one which pays her the most.
This BIP allows BMM Requests to take place over Lightning. One method is [https://www.drivechain.info/media/bmm-note/bmm-lightning/ here]. (BMM Accepts cannot be over LN, since they reside in main:coinbase txns.)
==Backward compatibility==
As a soft fork, older software will continue to operate without modification. 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 soft fork, older software will continue to operate without modification. To enforce BMM trustlessly, nodes must watch "pairs" of transactions, and subject them to extra rules. Non-upgraded nodes will notice that this activity is present in the blockchain, but they will not understand any of it.
(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.)
Much like P2SH or a new OP Code, these old users can never be directly affected by the fork, as they will have no expectations of receiving payments of this kind. (As a matter of fact, the only people receiving BTC here, all happen to be miners. So there is less reason than ever to expect compatibility problems.)
As with all previous soft forks, non-upgraded users are indirectly affected, in that they are no longer performing full validation.
==Deployment==
@ -196,8 +166,8 @@ This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and usi
<pre>
// Deployment of Drivechains (BIPX, BIPY)
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1642276800; // January 15th, 2022.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1673812800; // January 15th, 2023.
</pre>
@ -224,3 +194,4 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam
==Copyright==
This BIP is licensed under the BSD 2-clause license.

BIN
bip-0301/bmm-dots-examples.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

BIN
bip-0301/m1-gui.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 110 KiB

BIN
bip-0301/sidechain-headers.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB