1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
<pre>
BIP: 301
Layer: Consensus (soft fork)
Title: Blind Merged Mining (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-0301
Status: Draft
Type: Standards Track
Created: 2019-07-23
License: BSD-2-Clause
</pre>
==Abstract==
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, 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==
"Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin).
However, traditional MM has two drawbacks:
# Miners must run a full node of the other chain(s). (Thus, they must run "non-Bitcoin" software which may be buggy.)
# Miners are paid on the other chain, in Alt-currency. (Miners who MM Namecoin, will earn NMC.)
==Notation and Example==
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".
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"
|-
! colspan="3" | Upon finding a sidechain block worth $2000...
|- style="font-weight:bold; text-decoration:underline;"
| Item
| Layer1 Miner ("Mary")
| Sidechain User ("Simon")
|-
| Runs a sidechain node?
| No
| Yes
|-
| How much hashing?
| 100%
| 0%
|-
| Coins collected, on Layer2
| $0
| $2000
|-
| Coins paid out, on Layer1
| $0
| $1999
|-
| Coins rec'd, on Layer1
| $1999
| $0
|-
| d(Net Worth)
| +$1999
| +$1
|}
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*.)
BIP-301 consists of two messages: "BMM Accept" and "BMM Request".
# "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*.
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" 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>
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/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.
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.
For each side:block that Simon wants to attempt, he broadcasts a txn containing the following as an OP_RETURN:
<pre>
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>
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 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 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==
This soft fork can be deployed without modifying Bitcoin Core at all (ie, via [https://bip300cusf.com/ CUSF]).
==Deployment==
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==
The enforcer is [https://github.com/LayerTwo-Labs/bip300301_enforcer/ here].
Also, several example L2s using BIP-301 are [https://releases.drivechain.info/ here].
==Copyright==
This BIP is licensed under the BSD 2-clause license.
|
