bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

mediawiki format

Browse Source
This commit is contained in:
Paul Sztorc 2018-02-10 16:30:07 -05:00
parent 8a8c6253be
commit 99f553025f
1 changed files with 45 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
hashrate-escrows.md → bip-hashrate-escrows.mediawiki
View File

@ -1,7 +1,6 @@
Header
=======
<pre>
BIP: ????
Layer: Consensus (soft fork)
Title: Hashrate Escrows (Consensus layer)
@ -14,10 +13,9 @@ Header
Created: 2017-08-14
License: BSD-2-Clause
Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
</pre>
Abstract
==========
==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.
@ -26,8 +24,7 @@ A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who w
This project has [a website](http://www.drivechain.info/) which includes [a FAQ](http://www.drivechain.info/faq/index.html).
Motivation
============
==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).
@ -40,22 +37,20 @@ Sidechains have many potential benefits, including:
Specification
==============
==Specification==
#### Components
==== Components ====
Hashrate Escrows are built of two types of component: [1] new databases, and [2] new message-interpretations.
##### 1. New Databases
===== 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
===== 2. New Messages =====
* M1. "Propose New Escrow"
* M2. "ACK Escrow Proposal"
@ -65,7 +60,7 @@ Please note that these structures (D1 and D2) will not literally exist anywhere
* M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main
#### On the Resource Requirements of New Databases
==== 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.
@ -74,9 +69,9 @@ In other words, we just rearrange what is already there. Because of this, even t
### Adding Sidechains and Tracking Them (D1, M1, M2)
=== Adding Sidechains and Tracking Them (D1, M1, M2) ===
#### D1 -- "Escrow_DB"
==== 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.
@ -97,7 +92,7 @@ Field No. | Label | Bytes | Type | Description / Purpose
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
====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.
@ -105,9 +100,9 @@ Escrow_DB requires 223 bytes [1+120+32+32+2+32+4] for each escrow in the main bl
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
====Notes on D1====
##### Obligations Placed on Miners
=====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").
@ -132,7 +127,7 @@ 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
===== 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.
@ -142,7 +137,7 @@ Currently, we use a process which may be suboptimal. It is that we *literally si
#### M1 -- "Propose New Sidechain"
==== M1 -- "Propose New Sidechain" ====
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 157 bytes (0x9d)
@ -150,7 +145,7 @@ Currently, we use a process which may be suboptimal. It is that we *literally si
153-byte - the critical bytes mentioned above (fields #1, #3, and #4, to populate a new D1 entry)
#### New Block Validation Rules
==== 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".
@ -158,19 +153,19 @@ Currently, we use a process which may be suboptimal. It is that we *literally si
* 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
==== 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"
==== 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
==== 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").
@ -178,9 +173,9 @@ The escrow will "reuse" the same address over and over. But notice that there is
### Adding Withdrawal-Attempts and Tracking Their Success (D2, M3, M4)
=== Adding Withdrawal-Attempts and Tracking Their Success (D2, M3, M4) ===
#### D2 -- "Withdrawal_DB"
==== D2 -- "Withdrawal_DB" ====
The table below enumerates the database fields, their size (in bytes), type and purpose.
@ -200,7 +195,7 @@ Field No. | Label | Bytes | Type | Description / Purpose
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
==== 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.
@ -210,7 +205,7 @@ Withdrawal_DB requires 46 bytes [1+32+2+3+2+3+2+1] per entry. Of these, 13 bytes
* * 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"
==== M3 -- "Propose Withdrawal" ====
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 37 bytes (0x25)
@ -218,21 +213,21 @@ Withdrawal_DB requires 46 bytes [1+32+2+3+2+3+2+1] per entry. Of these, 13 bytes
33-byte - the critical bytes mentioned above (fields #1 and #2, to populate a new D2 entry)
#### New Block Validation Rules for M3
==== 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"
==== M4 -- "ACK Withdrawal" ====
#### Very Little Info, Probably Calculable in Advance
==== 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
==== 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.
@ -246,7 +241,7 @@ Second, n=2 can be implemented in a clever way: by allowing a withdrawal to free
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?
==== How Hard is it to Guess M4? ====
If there are n Escrows and m Withdrawals-per-escrow<sup>1</sup>, then there are (m+2)^n total candidates for the next D2. This is because, [per block per escrow], one of three things can happen: (1) one of the m withdrawal-candidates can be "ACK"ed (or "upvoted" or "promoted"), which automatically downvotes the others; or (2) all withdrawal-candidates can be downvoted, or finally (3) the miners can abstain from voting on the escrow's withdrawals altogether, leaving the tallies the same.
@ -254,7 +249,7 @@ First, for nodes which validate all sidechains (assuming these escrows are sidec
Of course, that is still O(k^n) for n sidechains, which isn't great<sup>2</sup>. If the "D2 update" cannot be guessed, it must be transmitted in some way.
#### Giving Up and Getting M4 the Old Fashioned Way
==== Giving Up and Getting M4 the Old Fashioned Way ====
Two examples for transmitting it are below:
@ -287,7 +282,7 @@ In practice, n is already capped, and miners may impose [on each other] a "soft
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)
===== 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:
@ -295,7 +290,7 @@ From one block to the next, D2 can only be edited in a few strict ways:
* 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
===== Footnotes for M4 =====
<sup>1</sup> This represents the worst-case scenario is one where all the Withdrawals are spread evenly over each Sidechain. Under normal operations, there is no reason to expect the all sidechains will have the same number of withdrawals at any given time. In fact, under normal operations, the very *concept* of counting the withdrawals-per-sidechain should be a purposeless one, because there should only be *one* withdrawal at a time. Nonetheless we consider the worst case scenario here.
@ -303,7 +298,7 @@ From one block to the next, D2 can only be edited in a few strict ways:
### Depositing and Withdrawing (M5, M6)
=== 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.
@ -319,7 +314,7 @@ These criteria are enforced here https://github.com/drivechain-project/bitcoin/b
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
==== M5. "Make a Deposit" -- a transfer of BTC from-main-to-side ====
As far as mainchain consensus is concerned, there are no additional requirements.
@ -327,14 +322,14 @@ However, in practice there *are* additional mainchain requirements...specified b
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
===== 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
==== 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.
@ -361,16 +356,16 @@ As a result of these requirements, every single withdrawal-attempt will fail, un
Backward compatibility
========================
==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
===========
==Deployment==
This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" and using bit 4.
@ -381,28 +376,25 @@ consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 151597440
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1547510401; // January 15th, 2019.
```
Reference Implementation
==========================
==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
============
==References==
See http://www.drivechain.info/literature/index.html
Credits
=========
==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
==========
==Copyright==
This BIP is licensed under the BSD 2-clause license.