mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Link to latest code -- also shorter/better explanations (#1666)
* Update to CUSF activation client +shorter +clearer * remove superfluous images * link to CUSF client, shorter and clearer BIP text
This commit is contained in:
Paul Sztorc
GitHub
parent
22660ad307
commit
34db0e99fa
@ -15,31 +15,28 @@
|
||||
|
||||
==Abstract==
|
||||
|
||||
In Bip300, txns are not signed via cryptographic key. Instead, they are "signed" by hashpower, over time. Like a big multisig, 13150-of-26300, where each block is a new "signature".
|
||||
BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys.
|
||||
|
||||
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).
|
||||
BIP-300 emphasizes slow, transparent, and auditable withdrawals that are easy for honest users to get right and hard for dishonest miners to abuse. The main design goal for BIP-300 is ''partitioning'' -- users can ignore BIP-300 txns if they wish; it makes no difference to L1 if the user validates all, some, or none of them. The second design goal is ''security'' -- users of the L2 should feel confident that, [https://www.drivechain.info/blog/fees/ if the L2 network is paying a lot of fees], then miners will want to keep it around, and the withdrawals will therefore be processed accurately.
|
||||
|
||||
See [http://www.drivechain.info/ this site] for more information.
|
||||
Once BIP-300 has established a "bridge" between L1 and these L2s, users can swap coins in and out instantly, only using BIP-300 for final settlement. This setup allows Bitcoin to process all the transactions in the world, of any shape or size, regardless of blocksize, node software, tech stack, or decentralization level -- all without altering L1 at all.
|
||||
|
||||
|
||||
==Motivation==
|
||||
|
||||
BIP-300 allows us to achieve [https://www.truthcoin.info/blog/zside-meltcast/ strong privacy], [https://www.truthcoin.info/blog/thunder/ planetary scale], and [https://www.truthcoin.info/blog/all-world-txns/ hundreds of billions of dollars in annual mining revenues], all with a [https://www.drivechain.info/blog/fees/ security model] that is [https://x.com/Truthcoin/status/1701959339508965405 much stronger than] that of the [https://www.truthcoin.info/blog/ln-blackpill/ Lightning Network].
|
||||
|
||||
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."
|
||||
The original motivation stretches back to Reid Hoffman, who [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."
|
||||
|
||||
Today, 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], 15x more txn fees are paid outside the BTC protocol, than within it.
|
||||
See [http://www.drivechain.info/ drivechain.info] for more information.
|
||||
|
||||
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==
|
||||
|
||||
===Overview===
|
||||
|
||||
Bip300 allows for six new blockchain messages (these have consensus significance):
|
||||
BIP-300 consists of six new blockchain messages:
|
||||
|
||||
* M1. "Propose New Sidechain"
|
||||
* M2. "ACK Proposal"
|
||||
@ -48,14 +45,15 @@ Bip300 allows for six new blockchain messages (these have consensus significance
|
||||
* M5. Deposit -- a transfer of BTC from-main-to-side
|
||||
* M6. Withdrawal -- a transfer of BTC from-side-to-main
|
||||
|
||||
Nodes organize those messages into two caches:
|
||||
|
||||
* D1. "The Sidechain List", which tracks the 256 Hashrate Escrows (Escrows are slots that a sidechain can live in).
|
||||
* D2. "The Withdrawal List", which tracks the withdrawal-Bundles (coins leaving a Sidechain).
|
||||
Nodes organize this data into [https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/master/src/bip300.rs#L79-L96 a few caches], mainly these two:
|
||||
|
||||
* D1. "The Sidechain List"
|
||||
* D2. "The Withdrawal List"
|
||||
|
||||
==== D1 (The Sidechain List) ====
|
||||
|
||||
D1 is a list of active sidechains. D1 is updated via M1 and M2.
|
||||
D1 is a list of active sidechains. D1 is populated via M1 and M2. Fields #9 and #10 are updated via M5 and M6.
|
||||
|
||||
{| class="wikitable"
|
||||
|- style="font-weight:bold; text-align:center; vertical-align:middle;"
|
||||
@ -87,12 +85,12 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2.
|
||||
| 5
|
||||
| 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.)
|
||||
| Intended as the sha256 hash of the tar.gz of the canonical sidechain software. (This is not enforced by BIP-300, and is for human purposes only.)
|
||||
|- style="vertical-align:middle;"
|
||||
| 6
|
||||
| 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.)
|
||||
| Intended as the git commit hash of the canonical sidechain node software. (This is not enforced by BIP-300, and is for human purposes only.)
|
||||
|-
|
||||
| 7
|
||||
| Active
|
||||
@ -118,17 +116,17 @@ D1 is a list of active sidechains. D1 is updated via M1 and M2.
|
||||
|
||||
==== D2 (The Withdrawal List) ====
|
||||
|
||||
D2 lists withdrawal-attempts. If these attempts succeed, they will pay coins "from" a Bip300-locked UTXO, to new UTXOs controlled by the withdrawing-user. Each attempt pays out many users, so we call these withdrawal-attempts "Bundles".
|
||||
Withdrawals are transactions that remove coins "from" L2 (i.e., from the BIP-300 locked UTXO), and place them back on L1. Each BIP-300 withdrawal can pay out up to 6,000 withdrawals, and only one withdrawal can succeed at a time (per L2). Therefore, since all L2 users share the same large withdrawal-event, on L1 we call these withdrawals "bundles".
|
||||
|
||||
D2 is driven by M3, M4, M5, and M6. Those messages enforce the following principles:
|
||||
|
||||
# The Bundles have a canonical order (first come first serve).
|
||||
# The database has a canonical order (first come first serve).
|
||||
# From one block to the next, every "Blocks Remaining" field decreases by 1.
|
||||
# When "Blocks Remaining" reaches zero the Bundle is removed.
|
||||
# When "Blocks Remaining" reaches zero, the bundle is removed.
|
||||
# From one block to the next, the value in "ACKs" may either increase or decrease, by a maximum of 1 (see M4).
|
||||
# If a Bundle's "ACKs" reach 13150 or greater, it "succeeds" and its corresponding M6 message can be included in a block.
|
||||
# If the M6 of a Bundle is paid out, it is also removed.
|
||||
# If a Bundle cannot possibly succeed ( 13150 - "ACKs" > "Blocks Remaining" ), it is removed immediately.
|
||||
# If a bundle's "ACKs" reach 13150 or greater, it "succeeds" and its corresponding M6 message can be included in a block.
|
||||
# If the M6 of a bundle is paid out, it is also removed.
|
||||
# If a bundle cannot possibly succeed ( 13150 - "ACKs" > "Blocks Remaining" ), it is removed immediately.
|
||||
|
||||
|
||||
{| class="wikitable"
|
||||
@ -145,7 +143,7 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip
|
||||
| 2
|
||||
| Bundle Hash
|
||||
| uint256
|
||||
| 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.
|
||||
| A withdrawal attempt. Specifically, it is a "blinded transaction id" (i.e., 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
|
||||
| Work Score (ACKs)
|
||||
@ -158,20 +156,12 @@ D2 is driven by M3, M4, M5, and M6. Those messages enforce the following princip
|
||||
| How long this bundle has left to live (measured in blocks). Starts at 26,300 and counts down.
|
||||
|}
|
||||
|
||||
D1, with all 256 slots active, reaches a maximum size of: 256 * ( 1 (map index) + 36 (outpoint) + 8 (amount) ) = 11,520 bytes.
|
||||
|
||||
D2, under normal conditions, would reach a size of: (38 bytes per withdrawal * 256 sidechains) = 9,728 bytes.
|
||||
|
||||
It is possible to spam D2. A miner can add the max M3s (256) every block, forever. This costs 9,728 on-chain bytes per block, an opportunity cost of about 43 txns. It results in no benefit to the miner whatsoever. D2 will eventually hit a ceiling at 124.5568 MB. (By comparison, the Bitcoin UTXO set is about 7,000 MB.) When the attacker stops, D2 will eventually shrink back down to 9,728 bytes.
|
||||
|
||||
|
||||
=== The Six New Bip300 Messages ===
|
||||
|
||||
First, how are new sidechains created?
|
||||
=== M1 -- Propose Sidechain ===
|
||||
|
||||
They are first proposed (with M1), and later acked (with M2). This process resembles Bip9 soft fork activation.
|
||||
|
||||
==== M1 -- Propose Sidechain ====
|
||||
New sidechains are proposed with M1, and ACKed with M2.
|
||||
|
||||
M1 is a coinbase OP Return output containing the following:
|
||||
|
||||
@ -197,7 +187,7 @@ Otherwise:
|
||||
* A new entry is added to D1, whose initial Activation Status is (age=0, fails=0).
|
||||
|
||||
|
||||
==== M2 -- ACK Sidechain Proposal ====
|
||||
=== M2 -- ACK Sidechain Proposal ===
|
||||
|
||||
M2 is a coinbase OP Return output containing the following:
|
||||
|
||||
@ -219,46 +209,32 @@ Otherwise:
|
||||
|
||||
A sidechain fails to activate if:
|
||||
|
||||
* If the slot is unused: during the next 2016 blocks, it accumulates 201 fails. (Ie, 90% threshold).
|
||||
* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails. (Ie, 50% threshold).
|
||||
* If the slot is unused: during the next 2016 blocks, it accumulates 1008 fails (i.e., 50% hashrate threshold).
|
||||
* If the slot is in use: during the next 26,300 blocks, it accumulates 13,150 fails (i.e., 50% hashrate threshold).
|
||||
|
||||
( Thus we can overwrite a used sidechain slot. Bip300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal) so this slot-overwrite option does not change the security assumptions. )
|
||||
( Thus we can overwrite a used sidechain slot. BIP-300 sidechains are already vulnerable to one catastrophe per 13150 blocks (the invalid withdrawal), so this slot-overwrite option does not change the security assumptions. )
|
||||
|
||||
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_DRIVECHAIN output. This output becomes the initial CTIP for the sidechain.
|
||||
|
||||
=== Withdrawing in Bundles ===
|
||||
|
||||
Sidechain withdrawals take the form of "bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare L1 transaction.
|
||||
|
||||
On the L2 side, individual withdrawal requests are periodically combined into a single CoinJoin-like withdrawal bundle. This bundle is hashed [https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L374C1-L419C2 in a particular way] (on both L2 and L1) -- this "blinded hash" commits to its own L1 fee, but (notably) it does not commit to its first tx-input (in that way, it is like [https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki BIP-118]).
|
||||
|
||||
This hash is what L1 miners will slowly ACK over 3-6 months, not the M6 itself (nor any sidechain data, of course).
|
||||
|
||||
A bundle will either pay all its withdrawals out (via M6), or fail (and pay nothing out for anyone).
|
||||
|
||||
|
||||
|
||||
==== Notes on Withdrawing Coins ====
|
||||
|
||||
Bip300 withdrawals ("M6") are very significant.
|
||||
|
||||
For an M6 to be valid, it must be first "prepped" by one M3 and then 13,150+ M4s. M3 and M4 are about "Bundles".
|
||||
|
||||
===== What are Bundles? =====
|
||||
|
||||
Sidechain withdrawals take the form of "Bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.
|
||||
|
||||
Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
|
||||
|
||||
This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
|
||||
|
||||
A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
|
||||
|
||||
===== Bundle Hash = Blinded TxID of M6 =====
|
||||
|
||||
The Bundle hash is static as it is being ACKed. Unfortunately, the M6 TxID will be constantly changing -- as users deposit to the sidechain, the input to M6 will change.
|
||||
|
||||
To solve this problem, we do something 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. These are: the first input and the first output. Via the former, a sidechain can accept deposits, even if we are acking a TxID that spends from it later. Via the latter, we can force all of the non-withdrawn coins to be returned to the sidechain (even if we don't yet know how many coins this will be).
|
||||
|
||||
==== M3 -- Propose Bundle ====
|
||||
=== M3 -- Propose Bundle ===
|
||||
|
||||
M3 is a coinbase OP Return output containing the following:
|
||||
|
||||
1-byte - OP_RETURN (0x6a)
|
||||
4-byte - Commitment header (0xD45AA943)
|
||||
32-byte - The Bundle hash, to populate a new D2 entry
|
||||
32-byte - The bundle hash, to populate a new D2 entry
|
||||
1-byte - nSidechain (the slot number)
|
||||
|
||||
M3 is ignored if it does not parse, or if it is for a sidechain that doesn't exist.
|
||||
@ -272,9 +248,10 @@ M3 is invalid if:
|
||||
|
||||
Otherwise: M3 adds an entry to D2, with initial ACK score = 1 and initial Blocks Remaining = 26,299. (Merely being added to D2, does count as your first upvote.)
|
||||
|
||||
Once a Bundle is in D2, how can we give it enough ACKs to make it valid?
|
||||
|
||||
==== M4 -- ACK Bundle(s) ====
|
||||
=== M4 -- ACK Bundle(s) ===
|
||||
|
||||
Once a bundle is in D2, how can we give it enough ACKs to make it valid?
|
||||
|
||||
M4 is a coinbase OP Return output containing the following:
|
||||
|
||||
@ -283,35 +260,25 @@ M4 is a coinbase OP Return output containing the following:
|
||||
1-byte - Version
|
||||
n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain.
|
||||
|
||||
The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted".
|
||||
|
||||
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 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 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.
|
||||
|
||||
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,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].
|
||||
|
||||
|
||||
The M4 message will be invalid (and invalidate the block), if:
|
||||
|
||||
* It tries to upvote a Bundle that doesn't exist. (For example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles.)
|
||||
* There are no Bundles at all, from any sidechain.
|
||||
* It tries to upvote a bundle that doesn't exist. (For example, trying to upvote the 7th bundle on sidechain #2, when sidechain #2 has only three bundles.)
|
||||
* There are no bundles at all, from any sidechain.
|
||||
|
||||
If M4 is NOT present in a block, then it is treated as "abstain".
|
||||
If M4 is NOT present in a block, then it is treated as an "abstain" for all sidechains.
|
||||
|
||||
If M4 is present and valid: each withdrawal-bundle that is ACKed, will gain one upvote.
|
||||
|
||||
Important: Within a sidechain-group, upvoting one Bundle ("+1") automatically downvotes ("-1") 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").
|
||||
Each sidechain always has two "virtual bundles" -- an "abstain" bundle (0xFF), and an "alarm" bundle (0xFE). Abstain leaves the ACK count unchanged, and alarm reduces all ACK counts of all bundles by 1.
|
||||
|
||||
For example:
|
||||
Any bundle which fails to receive a vote, is downvoted (and loses 1 ACK). If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
|
||||
|
||||
|
||||
==== Examples ====
|
||||
|
||||
To upvote the 7th bundle on sidechain #1, and upvote the 4th bundle on sidechain #2, the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
|
||||
|
||||
If block 900,000 has D2 of...
|
||||
|
||||
{| class="wikitable"
|
||||
|-
|
||||
@ -347,7 +314,7 @@ For example:
|
||||
|}
|
||||
|
||||
|
||||
...in block 900,000 could become...
|
||||
...and then D2 wants to become:
|
||||
|
||||
|
||||
{| class="wikitable"
|
||||
@ -383,18 +350,29 @@ For example:
|
||||
| 22,559
|
||||
|}
|
||||
|
||||
...if M4 were [0x6A,D77D1776,00,0000,0001].
|
||||
... then M4 would have been [0x6A,D77D1776,00,0000,0001].
|
||||
|
||||
==== Saving Space ====
|
||||
|
||||
The version number allows us to shrink the upvote vector in many cases.
|
||||
Version 0x00 omits the upvote vector entirely (i.e., 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
|
||||
Version 0x01 uses 1 byte per sidechain, and can be used while all ACKed withdrawals have an index <256 (i.e., 99.99%+ of the time).
|
||||
Version 0x02 uses 2 bytes per sidechain, but it always works, even in astronomically unlikely cases (such as when >1 sidechains have >256 bundle candidates).
|
||||
Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.
|
||||
|
||||
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].
|
||||
|
||||
|
||||
Finally, we describe Deposits and Withdrawals.
|
||||
|
||||
==== M5 -- Deposit BTC to Sidechain ====
|
||||
=== M5 -- Deposit BTC (from L1 to L2) ===
|
||||
|
||||
Each sidechain stores all its BTC in one UTXO, called the "CTIP".
|
||||
Finally, we describe Deposits (M5) and Withdrawals (M6). These are not coinbase outputs, they are txns on L1.
|
||||
|
||||
By definition, an M5 is a transaction which spends the CTIP and '''increases''' the quantity of coins. An M6 is a transaction which spends the CTIP and '''decreases''' the quantity of coins in the CTIP. See [https://github.com/LayerTwo-Labs/mainchain/blob/391ab390adaa19f92871d769f8e120ca62c1cf14/src/validation.cpp#L688-L801 here].
|
||||
We call a transaction "M5" if it spends from the escrow output and '''increases''' the quantity of coins. Conversely, we call a transaction "M6" if it spends from the escrow output and '''decreases''' the quantity of coins. See [https://github.com/LayerTwo-Labs/bip300301_enforcer/blob/master/src/bip300.rs#L462C1-L462C47 here].
|
||||
|
||||
Every time a deposit/withdrawal is made, the old CTIP is spent and a new one is created. (Deposits/Withdrawals never cause UTXO bloat.) At all times, the CTIP of each sidechain is cached in D1 (above).
|
||||
Every time a deposit/withdrawal is made, the old UTXO is spent and a single new UTXO is created. (Deposits/Withdrawals never cause UTXO bloat.) At all times, the specific treasury UTXO ("CTIP") of each sidechain is cached in D1 (above).
|
||||
|
||||
Every M5 is valid, as long as:
|
||||
|
||||
@ -402,19 +380,18 @@ Every M5 is valid, as long as:
|
||||
* The new CTIP has '''more''' coins in it, than before.
|
||||
|
||||
|
||||
==== M6 -- Withdraw BTC from a Sidechain ====
|
||||
=== M6 -- Withdraw BTC (from L2 to L1) ===
|
||||
|
||||
We come, finally, to the critical matter: where users can take their money *out* of the sidechain.
|
||||
|
||||
M6 is invalid if:
|
||||
|
||||
* 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 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_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 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.
|
||||
* There are additional OP_DRIVECHAIN outputs after the first one.
|
||||
|
||||
Else, M6 is valid.
|
||||
Else, M6 is valid -- and the funds are withdrawn.
|
||||
|
||||
(The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.)
|
||||
|
||||
@ -429,6 +406,8 @@ without it, sidechain numbers 0 and 128 would cause the legacy script interprete
|
||||
|
||||
If an OP_DRIVECHAIN input is spent, the additional rules for M5 or M6 (see above) must be enforced.
|
||||
|
||||
<!--
|
||||
|
||||
====Weight adjustments====
|
||||
|
||||
To account for the additional drivechain checks, each message adds to the block's weight:
|
||||
@ -449,7 +428,7 @@ To account for the additional drivechain checks, each message adds to the block'
|
||||
| M6 || 352
|
||||
|}
|
||||
|
||||
<!--
|
||||
|
||||
get: 168 WU for 1 byte
|
||||
delete: free?
|
||||
create: 168 WU for 33 bytes
|
||||
@ -476,35 +455,25 @@ M5/M6 OP_DRIVECHAIN spends require 2 additional input lookups
|
||||
-->
|
||||
|
||||
|
||||
|
||||
|
||||
==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 these UTXOs 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 all different sidechain-nodes will always report the same Bundle, is to upgrade sidechains via soft forks of themselves. )
|
||||
This soft fork can be deployed without modifying Bitcoin Core at all (i.e., via [https://bip300cusf.com/ CUSF]).
|
||||
|
||||
|
||||
==Deployment==
|
||||
|
||||
This BIP will be deployed via UASF-style block height activation. Block height TBD.
|
||||
This BIP deploys when/if >51% hashrate runs [https://github.com/LayerTwo-Labs/bip300301_enforcer/ the enforcer client].
|
||||
|
||||
Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.
|
||||
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
See: https://github.com/drivechain-project/mainchain
|
||||
The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
|
||||
|
||||
Also, for interest, see an example sidechain here: https://github.com/drivechain-project/sidechains/tree/testchain
|
||||
|
||||
|
||||
==References==
|
||||
|
||||
https://github.com/drivechain-project/mainchain
|
||||
https://github.com/drivechain-project/sidechains/tree/testchain
|
||||
See http://www.drivechain.info/literature/index.html
|
||||
|
||||
|
||||
==Credits==
|
||||
|
||||
Thanks to everyone who contributed to the discussion, especially: Luke Dashjr, 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.
|
||||
Also, several example L2s are [https://releases.drivechain.info/ here].
|
||||
|
||||
|
||||
==Copyright==
|
||||
|
||||
@ -15,9 +15,9 @@
|
||||
|
||||
==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) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
|
||||
|
||||
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.
|
||||
Instead, this block-assembly work is done by alt-chain users. They choose the alt-chain block, and what txns go in it, the fees etc. Simultaneously, these users "bid" on L1 to win the right to be the sole creator of the alt-chain block. BIP-301 ensures that L1 miners only accept one bid (per 10 minutes, per L2 category), instead of taking all of them (which is what they would ordinarily do).
|
||||
|
||||
|
||||
==Motivation==
|
||||
@ -32,9 +32,9 @@ However, traditional MM has two drawbacks:
|
||||
|
||||
==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".
|
||||
We use notation side:\* and main:\* in front of otherwise ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain/alt-chain 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").
|
||||
Furthermore, here is an example of BIP-301 in use. Imagine that a side:block contains 20,000 txns, each paying a $0.10 fee; therefore, the side:block is worth $2000 of fee revenue. In BIP-301, the sidechain's coinbase txn will pay this $2000 to "Simon". Simon does no hashing, but instead makes one L1 txn paying $1999 to the L1 miners ("Mary"). Thus, Mary ends up with all of the fee revenue, even though she didn't do anything on the sidechain.
|
||||
|
||||
|
||||
{| class="wikitable"
|
||||
@ -71,119 +71,88 @@ Example: imagine that a sidechain block contains 20,000 txns, each paying a $0.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.
|
||||
BIP-301 makes this specialization-of-labor trustless on L1. If Mary takes Simon's money, then she must let Simon control the side:block.
|
||||
|
||||
|
||||
|
||||
==Specification==
|
||||
|
||||
Each candidate for next side:block is defined by its unique side:blockhash "h*". (Even if the entire rest of the L2 block is identical, different Simons will have different side:coinbases and therefore different h*.)
|
||||
|
||||
Bip301 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*".
|
||||
BIP-301 consists of two messages: "BMM Accept" and "BMM Request".
|
||||
|
||||
So we will discuss:
|
||||
# "BMM Accept" -- A coinbase output in L1, which contains h*. Mary can only choose one h* to endorse.
|
||||
# "BMM Request" -- A transaction where Simon offers to pay Mary, if (and only if) Mary's L1 block contains Simon's h*.
|
||||
|
||||
# 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".
|
||||
As a miner, Mary controls the main:coinbase, so she may select any h*. Her selection determines which side:block is "found" -- and which associated BMM Request she can collect.
|
||||
|
||||
|
||||
=== BMM Accept ===
|
||||
|
||||
To "Accept" the BMM proposal (and to accept Simon's money), Mary must endorse Simon's block.
|
||||
To "Accept" a BMM proposal (endorsing Simon's side:block, and allowing Mary to accept Simon's money later in the block), Mary places an OP_RETURN output into the main:coinbase as follows:
|
||||
|
||||
<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)
|
||||
1-byte - Sidechain number (0-255)
|
||||
32-bytes - h* (obtained from Simon)
|
||||
</pre>
|
||||
|
||||
[https://github.com/drivechain-project/mainchain/blob/8901d469975752d799b6a7a61d4e00a9a124028f/src/validation.cpp#L3530-L3572 Code details here].
|
||||
[https://github.com/LayerTwo-Labs/bip300301_messages/blob/master/src/lib.rs#L252-L264 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.
|
||||
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 ===
|
||||
|
||||
Simon will use BMM Requests to buy the right to find a sidechain block, from Mary.
|
||||
Simon will use BMM Requests to buy the "right" to find a sidechain block, from Mary.
|
||||
|
||||
For each side:block that Simon wants to attempt, he broadcasts a txn containing the following as an OP_RETURN:
|
||||
|
||||
<pre>
|
||||
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)
|
||||
1-byte - OP_RETURN (0x6a)
|
||||
3-bytes - Message header (0x00bf00)
|
||||
1-byte - Sidechain number (0-255)
|
||||
32-bytes - h* (obtained from L2 node)
|
||||
32-bytes - prevMainBlock (the blockhash of the previous main:block)
|
||||
</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.)
|
||||
|
||||
|
||||
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).
|
||||
h* is chosen by Simon to correspond to the side:block he wants to mine on the alt-chain. nSidechain is the number assigned to the sidechain/alt-chain when it was created.
|
||||
|
||||
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).
|
||||
# Only one BMM Request is allowed in each main:block, per nSidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must single out one BMM_Request_4 to include in this L1 block.
|
||||
# The 32-bytes of prevMainBlock must match the previous main:blockhash. Thus, Simon's txns are only valid for the current block, in the block history that he knows about.
|
||||
|
||||
|
||||
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.
|
||||
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 enter the L1 block, Simon may feel comfortable making multiple offers all day long. This means Mary has many offers to choose from, and can choose the one that 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. 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.
|
||||
|
||||
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.
|
||||
This soft fork can be deployed without modifying Bitcoin Core at all (ie, via [https://bip300cusf.com/ CUSF]).
|
||||
|
||||
|
||||
==Deployment==
|
||||
|
||||
This BIP will be deployed via UASF-style block height activation. Block height TBD.
|
||||
This BIP deploys when/if >51% hashrate runs [https://github.com/LayerTwo-Labs/bip300301_enforcer/ the enforcer client].
|
||||
|
||||
Ideally, a critical mass of users would also run the enforcer client -- this would strongly dissuade miners from ever de-activating it.
|
||||
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
See: https://github.com/drivechain-project/mainchain
|
||||
The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
|
||||
|
||||
Also, for interest, see an example sidechain here: https://github.com/drivechain-project/sidechains/tree/testchain
|
||||
|
||||
|
||||
==References==
|
||||
|
||||
* http://www.drivechain.info/literature/index.html
|
||||
* http://www.truthcoin.info/blog/blind-merged-mining/
|
||||
* http://www.truthcoin.info/images/bmm-outline.txt
|
||||
|
||||
|
||||
==Thanks==
|
||||
|
||||
Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber.
|
||||
Also, several example L2s using BIP-301 are [https://releases.drivechain.info/ here].
|
||||
|
||||
|
||||
==Copyright==
|
||||
|
||||
This BIP is licensed under the BSD 2-clause license.
|
||||
|
||||
|
||||
@ -1 +0,0 @@
|
||||
Images used as reference in the documentation.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 262 KiB |
Loading…
Reference in New Issue
Block a user