BIP 0300 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/979ee894b8a4a2e9/bip-0300.mediawiki

2024-04-23T21:44:06Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/979ee894b8a4a2e9/bip-0300.mediawiki

← Older revision		Revision as of 21:44, 23 April 2024
Line 294:		Line 294:
	Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.		Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
	Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).		Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).
	Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many ~~withdrawl~~ proposals exist.		Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist.
	Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.		Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.

Line 469:		Line 469:
	for each coinbase output: search for prior M3 for this sidechain		for each coinbase output: search for prior M3 for this sidechain
	lookup if M3 was ever rejected or paid in the past		lookup if M3 was ever rejected or paid in the past
	for each prior proposed ~~withdrawl~~: (included in 1 get+delete+create)		for each prior proposed withdrawal: (included in 1 get+delete+create)
	M4: 1 get		M4: 1 get
	+ for every proposed withdraw, 1 get, 1 delete, 1 create, 1 add		+ for every proposed withdraw, 1 get, 1 delete, 1 create, 1 add

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e643d247c8bc0867/bip-0300.mediawiki

2023-08-18T02:15:51Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/e643d247c8bc0867/bip-0300.mediawiki

@@ Line 230: / Line 230: @@
 Otherwise, the sidechain activates (Active is set to TRUE).
-In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_TRUE. This output becomes the initial CTIP for the sidechain.
+In the block in which the sidechain activates, the coinbase MUST include at least one 0-valued OP_DRIVECHAIN output. This output becomes the initial CTIP for the sidechain.
@@ Line 291: / Line 291: @@
 For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
-The version number allows us to shrink the upvote vector in many cases. Version 0x00 requires a full two bytes per sidechain, but it always works. Version 0x01 uses half that (one byte per sidechain), and it works while all sidechains have fewer than 255 disputed withdrawals (ie, 99.99%+ of the time). Version 0x02 uses zero bytes (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4. Version 0x03 upvotes only those withdrawals that are leading their rivals by at least 50 votes.
+The version number allows us to shrink the upvote vector in many cases.
 If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
-For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,00,00]. It means: "upvote the first bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed).
+For example, an upvote vector of { 2 , N/A, 1 } would be represented as [0x6A,D77D1776,01,01,00]. It means: "upvote the second bundle in sidechain #1; and the first bundle in sidechain #3" (iff sidechains #2 has no bundles proposed).
 An upvote vector of { N/A, N/A, 4 } would be [0x6A,D77D1776,01,03].
@@ Line 398: / Line 402: @@
 Every M5 is valid, as long as:
-* It has at least one OP_TRUE output -- this becomes the new CTIP.
+* It has exactly one OP_DRIVECHAIN output -- this becomes the new CTIP.
 * The new CTIP has '''more''' coins in it, than before.
@@ Line 409: / Line 413: @@
 * The blinded hash of M6 does NOT match one of the approved Bundle-hashes.  (In other words: M6 must first be approved by 13,150 upvotes.)
-* The first output of M6 is NOT an OP_TRUE. (This OP_TRUE becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.)
+* The first output of M6 is NOT an OP_DRIVECHAIN. (This OP_DRIVECHAIN becomes the new CTIP. In other words: all non-withdrawn coins are paid back to the sidechain.)
-* The second output is NOT an OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount.
+* The second output is NOT a zero-value OP_RETURN script of exactly 10 bytes, of which 8 bytes are a serialized Bitcoin amount.
 * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point.
 Else, M6 is valid.
@@ Line 417: / Line 422: @@
 (The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.)

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/55566a73f9ddf77b/bip-0300.mediawiki

2023-07-18T01:55:05Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/55566a73f9ddf77b/bip-0300.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/40aef277672e28af/bip-0300.mediawiki

2022-09-29T23:03:37Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/40aef277672e28af/bip-0300.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0300.mediawiki

2022-08-04T11:55:15Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0300.mediawiki

← Older revision		Revision as of 11:55, 4 August 2022
Line 214:		Line 214:
	\| ACKs (Work Score)		\| ACKs (Work Score)
	\| uint16_t		\| uint16_t
	\| The current total number of ACKs (the PoW that has been used to validate the Bundle).		\| The current ACK-counter, which is the total number of ACKs (the PoW that has been used to validate the Bundle).
	\|-		\|-
	\| 4		\| 4
Line 230:		Line 230:
	# From one block to the next, "Age" fields must increase by exactly 1 (ie, Blocks Remaining decreases by 1).		# 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).		# 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).		# From one block to the next, the value in the ACKs field (ACK-counter) can increase or decrease by a maximum of 1 (see below).

	If a Bundle succeeds (in D2), it "becomes" an M6 message and is included in a block.		If a Bundle succeeds (in D2), it "becomes" an M6 message and is included in a block.
Line 258:		Line 258:

	* The ACK-counter of any Bundle can only change by (-1,0,+1).		* 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.		* Within a sidechain-group, upvoting one Bundle ("+1") requires you to downvote all other Bundles in that group. However, the minimum ACK-counter 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").		* 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").

Line 289:		Line 289:
	We come, finally, to the critical matter: where users can take their money out of the sidechain.		We come, finally, to the critical matter: where users can take their money out of the sidechain.

	In each block, a Bundle in D2 is considered "approved" if its "~~ACKs~~" value meets the threshold (13,150).		In each block, a Bundle in D2 is considered "approved" if its "ACK-counter" value meets the threshold (13,150).

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0300.mediawiki

2021-12-26T13:36:48Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0300.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0300.mediawiki

2019-09-24T18:00:23Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0300.mediawiki

New page

{{bip}}
{{BipMoved|bip-0300.mediawiki}}

<pre>
BIP: 300
Layer: Consensus (soft fork)
Title: Hashrate Escrows (Consensus layer)
Author: Paul Sztorc <truthcoin@gmail.com>
CryptAxe <cryptaxe@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0300
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
</pre>

==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].

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.

This project has [http://www.drivechain.info/ a website] which includes [http://www.drivechain.info/faq/index.html an 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:

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

==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

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

{| class="wikitable"
! Field No.
! Label
! Type
! Description / Purpose
|-
| 1
| Escrow Number
| uint8_t
| A number assigned to the entire escrow. Used to make it easy to refer to each escrow.
|-
| 2
| Sidechain Deposit Script Hex
| string
| The script that will be deposited to, and update the CTIP of the sidechain.
|-
| 3
| Sidechain Private Key
| string
| The private key of the sidechain deposit script.
|-
| 4
| Escrow 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.
|-
| 7
| Hash ID 2
| uint256
| A field of 32 bytes, which could be any bytes such as a sha256 hash.
|-
| 8
| "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
| "CTIP" -- Part 2 "Index"
| int32_t
| Of the CTIP, this is second element of the pair: the Index. See #9 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.

==== M2 -- "ACK Sidechain Proposal" ====

1-byte - OP_RETURN (0x6a)
4-byte - Commitment header (0xD6E1C5BF)
32-byte - Commitment hash: sha256D hash of sidechain's serialization

==== New Block Validation Rules ====

# 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).

=== Withdrawing from Escrows (D2, M3, M4) ===

==== D2 -- "Withdrawal_DB" ====

D2 changes deterministically with respect to M3, M4, M5, and M6.

{| class="wikitable"
! Field No.
! Label
! Type
! Description / Purpose
|-
| 1
| Escrow Number
| uint8_t
| Links the withdrawal-request to a specific escrow.
|-
| 2
| WT^ 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.
|-
| 3
| ACKs (Work Score)
| uint16_t
| The current total number of ACKs (PoW)
|-
| 4
| Blocks Remaining (Age)
| uint16_t
| The number of blocks which this WT^ has remaining to accumulate ACKs
|}

==== New Block Validation Rules for D2 ====

# 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^").

In addition, there are special rules for the "ACKs" field (see M4 below).

==== M3 -- "Propose Withdrawal" ====

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

==== 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" ====

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").

One option for explicit transmission of M4 is:

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, ...]

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.

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)].

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

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

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

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

In each block, a withdrawal 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.

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.
# "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. )

==Deployment==

This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" and using bit 4.

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

==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==

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.