mirror of
https://github.com/bitcoin/bips.git
synced 2025-05-12 12:03:29 +00:00
fix mediawiki formatting
This commit is contained in:
Paul Sztorc
parent
99f553025f
commit
9207df7d05
@ -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.
|
||||
|
||||
|
||||
<img src="bip-hasrate-escrows/two-groups.png?raw=true" align="middle"></img>
|
||||
|
||||
The worst-case withdrawal time obeys f(n)=3+(3/n) months, where n is the number of simultaneous withdrawals.
|
||||
|
||||
@ -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"<sup>2</sup>, in which many miners create bad WT^s, vote on these randomly, and then refuse to broadcast their votes. Fortunately, even for a worst-case scenario of 200 sidechains and 1,000 withdrawal-attempts per sidechain, honest nodes can communicate a long form M4 with each other by using just 25,056 bytes per block [4+1+1+(200\*(1000+1+1)/8)].
|
||||
|
||||
Today's pre-drivechain miners can already carry out a similar attack, by creating and including txns and then not broadcasting that part of the block to anyone. This is often characterized as a ["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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user