BIP 301: Blind Merged Mining (Consensus layer)

psztorc commented at 2:44 am on February 4, 2018: contributor

This is a draft of a bip for blind merged mining, the second of two drivechain bips.

Create images.txt 0a1d35877a

Add files via upload db86b890f9

Add files via upload 2580d65228

Add files via upload da2e5745f3

Delete bip-hashrate-escrows.md 1af547cf72

one bip at a time 4bea2ef2b6

Delete images.txt 39a8bec6b7

Delete two-groups.png 3246096174

TheBlueMatt commented at 2:51 am on February 4, 2018: contributor

Seems reasonable to just merge with a “received only limited feedback, which was largely left unaddressed” header tag.

On February 4, 2018 2:44:03 AM UTC, Paul Sztorc notifications@github.com wrote:

This is a draft of a bip for blind merged mining, the second of two drivechain bips. You can view, comment on, or merge this pull request online at:

#643

– Commit Summary –

Create images.txt

Add files via upload

Add files via upload

Add files via upload

Delete bip-hashrate-escrows.md

Delete images.txt

Delete two-groups.png

– File Changes –

A bip-blind-merged-mining.md (329) A bip-blind-merged-mining/bmm-dots-examples.png (0) A bip-blind-merged-mining/images.txt (1) A bip-blind-merged-mining/witness-vs-critical.png (0)

– Patch Links –

https://github.com/bitcoin/bips/pull/643.patch https://github.com/bitcoin/bips/pull/643.diff

– You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bips/pull/643

luke-jr added the label New BIP on Feb 5, 2018

in bip-blind-merged-mining.md:61 in 3246096174 outdated

56+
57+### Sidechain Critical Data ("Sidechain Mini-Header")
58+
59+Specifically, per side:block per side:chain, we track the following 35 bytes of information:
60+
61+    1-byte   - ChainIndex (known as "Account Number" in hashrate-escrows.md , or as "Sidechain Number")

luke-jr commented at 2:15 am on February 6, 2018:

Where is this file?

psztorc commented at 10:36 pm on February 10, 2018:

Now, it is here, in the first BIP: https://github.com/bitcoin/bips/pull/642/files#diff-faa5d00974be8fe9f13c7d7fec81b7ee

in bip-blind-merged-mining.md:28 in 3246096174 outdated

23+
24+
25+Abstract
26+==========
27+
28+Blind Merged Mining (BMM) is a way of mining special extension blocks, ie "sidechains". It produces strong guarantees that the block is valid, for *any* arbitrary set of rules; and yet it does so without requiring miners to actually do any validation on the block whatsoever.

luke-jr commented at 2:20 am on February 6, 2018:

Extension blocks and sidechains are two different things.

psztorc commented at 10:38 pm on February 10, 2018:

They are indeed. I feel that an asymmetric sidechain is the same as an optional extension block. I will clarify it.

in bip-blind-merged-mining.md:83 in 3246096174 outdated

78+
79+![dots-image](/bip-blind-merged-mining/bmm-dots-examples.png?raw=true)
80+
81+Since the hashes themselves are already ordered by the mainchain, tracing the blockchain's path by index (prevBlockRef) will be the same as tracing it by identifying a list of hashes. In other words, the ordering given via each side:block's "prevBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ... if "prevSideHeaderHash is defined to be the sidechain's equivalent of the mainchain's "prevBlockHash". It will be possible to freely convert from one to the other. See M8 to learn more about how these hashes are requested by sidechain block creators to be included in the mainchain.
82+
83+Now that we know what our critical data is, and how it is made, how is this data broadcast and stored?

luke-jr commented at 4:21 am on February 6, 2018:

It’s not made clear why this data is considered critical… It certainly doesn’t seem like it should be.

psztorc commented at 10:44 pm on February 10, 2018:

I have clarified this part by adding: " This data is “critical” in the sense that it is the minimum amount of data required to define a sidechain. "

in bip-blind-merged-mining.md:98 in 3246096174 outdated

93+    1-byte - OP_RETURN (0x6a)
94+    1-byte - Push the following (4+(n*35)) bytes (0x??)
95+    4-byte - Message header (0xD3407053)
96+    (n*(32+5))-byte - A sequence of bytes, of the three Mini-Header items (h*, prevBlockRef, ChainIndex).
97+
98+( We assume that 5 bytes are used for the Critical Data bytes (non h* parts of the Sidechain Mini-Header). For 256 sidechains, a total of 9,478 bytes [1+1+4+256\*(32+5)] are required, conveniently just below the 10 KB scriptPubKey size limit.)

luke-jr commented at 4:22 am on February 6, 2018:

Why? This is useless data to the main chain.

psztorc commented at 10:44 pm on February 10, 2018:

The mainchain needs this data in order to validate the two styles of “M8” transaction.

in bip-blind-merged-mining.md:144 in 3246096174 outdated

139+
140+### M8 -- Paying miners to include BMM data in their coinbase outputs
141+
142+This section introduces a new type of transaction, which allows sidechain block creators to request, and pay for, a critical hash to be included in a specific block by mainchain miners. See [the Blind Merged Mining spec](http://www.truthcoin.info/blog/blind-merged-mining/). This txn allows miners to "sell" the act of mining a sidechain block. By taking advantage of this option, miners earn tx fees for mining sidechains...truly "for free". They do not even need to run sidechain nodes, and the tx-fees they earn are in mainchain BTC. As a result, sidechains affect all miners equally and do not affect the mining ecosystem.
143+
144+M8 will ultimately come in two versions. The second version will be specialized for use in the Lightning Network and must use the full 32-byte prevBlockHash (ironically, this larger transaction is cheaper for the Bitcoin network to process, as it is completely off-chain). The first version of M8, in contrast, cannot be used inside the Lightning Network, but is slightly more space-efficient (using the 2 prevBlockRef bytes to maintain chain order). It is important to make both options available to the user, because some side:nodes may be unwilling or unable to open a payment channels with each main:miner. However, in the long run we expect the lightning version to be preferred.

luke-jr commented at 4:27 am on February 6, 2018:

Lightning doesn’t require you to have a channel with the recipient…

psztorc commented at 10:46 pm on February 10, 2018:

Yes, I have edited this part to instead read “LN connection”. Although, it does not change the point I was trying to make.

in bip-blind-merged-mining.md:44 in 3246096174 outdated

39+Motivation
40+============
41+
42+Regular "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:
43+
44+1. Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.)

luke-jr commented at 4:33 am on February 6, 2018:

They can take a merged chain header from someone else risk-free.

psztorc commented at 10:47 pm on February 10, 2018:

Is there not a risk that they will get a merged chain header that is ultimately invalid (as I say above)? If so than it is not risk free.

in bip-blind-merged-mining.md:45 in 3246096174 outdated

40+============
41+
42+Regular "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:
43+
44+1. Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.)
45+2. Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity).

luke-jr commented at 4:34 am on February 6, 2018:

They can accept payment in any way they like… nothing stops them from being paid in bitcoins to include the mentioned merge block header.

psztorc commented at 10:49 pm on February 10, 2018:

The goal here is to make it require zero trust.

The issue is not being paid in BTC (as they will also be paid “in BTC” if they mine a namecoin sidechain [instead of namecoin-altcoin]). Instead, the issue is being paid on the mainchain.

luke-jr changes_requested

luke-jr commented at 4:34 am on February 6, 2018: member

BIPs are Mediawiki format, not Markdown.

This fails to address backward compatibility.

Furthermore, the spec itself seems strictly inferior to the older merge mining protocol as used by Namecoin etc. The alleged shortcomings this BIP claims the older protocol has, are not in fact true.

Some actual shortcomings in this BIP:

Requires changes to the Bitcoin protocol.
Limited to merely 256 sidechains.
Requires conveying the prevblock for no apparent reason.
Requires softforks for sidechains.
Includes information on sequence of sidechains in the mainchain for no apparent reason. (Skip count is especially redundant since the prev is already explicit)
No merkle tree for sidechain data!
Requires full nodes maintain a new database.
Requires finding a Bitcoin block for any merged chains.

re-reverse the bips

this is what I originally intended, but I forked this branch at the wrong time

8a8c6253be

mediawiki format 99f553025f

fix mediawiki formatting 9207df7d05

typos 486505b8fa

resync 68918ad24a

switch to mediawiki format 70f0ed6c39

typos 5418516065

move Chris

CS indicated via tweet that he felt he did not contribute enough to be a co-author

17db87224d

Merge pull request #1 from psztorc/blind-merged-mining

updates

cebe06b149

psztorc commented at 11:12 pm on February 10, 2018: contributor

Furthermore, the spec itself seems strictly inferior to the older merge mining protocol as used by Namecoin etc. The alleged shortcomings this BIP claims the older protocol has, are not in fact true.

These shortcomings are not even issues that I feel strongly about. But they are issues which are constantly raised by Matt Corallo and Peter Todd specifically. They are in Section 4.3 of Blockstream’s sidechains whitepaper as well as in this podcast.

I feel that pool operators will just run all of these nodes from a safe place, and then send as little data as possible to the hashers (the physical ASICs). Perhaps you agree with me, but other people don’t agree with us!!

Some actual shortcomings in this BIP:

Requires changes to the Bitcoin protocol.

Yes

Limited to merely 256 sidechains.

Of course, we can have sidechains of sidechains, so the real number is unlimited. And we could simply soft fork BMM into the mainchain a second time (for example to add 256 more).

I really do not think there will be more than 256, but I suppose we can’t know for sure.

Requires conveying the prevblock for no apparent reason. Includes information on sequence of sidechains in the mainchain for no apparent reason. (Skip count is especially redundant since the prev is already explicit)

You may have misunderstood the intent here. It is all about creating the conditions for M8, which is the way that sidechain nodes “buy” space in the main:coinbase_txn . To do this, the M8 payment must trigger on something. In fact, we have two possible versions of M8. One triggers on prev, the other on skip count. The ideal M8 payment is M8_v2 a lightning network payment that triggers on prev. But when we need to resort to an on-chain txn then we must use M8_v1. M8_v1, however, unlike the LN payment, can trigger using the index. It actually saves 30 bytes (although the LN txn is better because it uses zero on-chain bytes).

Requires softforks for sidechains.

There are a few reasons why this is a good idea. One is that, if miners do not support a sidechain, it is in danger of having its funds lost, trapped, or stolen. Another is that is not a big deal, because we expect profit-seeking miners to want to add sidechains, as these increase the value of mined BTC as well as miner’s total tx-fee revenues.

More important reasons are here: http://www.drivechain.info/faq/#categorical-control

No merkle tree for sidechain data!

All of the data here is mandatory, so a merkle tree would only accomplish two things (as I see it): first, it would waste 32 bytes of space, to accommodate the (pointless) root hash ; and second, it would be a SegWit-like “evil fork” increasing the blocksize limit arbitrarily (or, I suppose, by 32*256 = 8192 bytes).

Requires full nodes maintain a new database.

This is a disadvantage of this proposal, yes. But the database is pretty small, if you ask me.

Requires finding a Bitcoin block for any merged chains.

I feel that the asymmetric model is by far the most practical way to develop sidechains tech. We get half of the problem solved for free, and we can leverage this solved half to make dealing with the unsolved half much easier. For these asymmetric sidechains, nothing is lost by this requirement.

clarifications + backward compatibility 2a981366e7

Merge pull request #2 from psztorc/blind-merged-mining

clarifications + backward compatibility

5353f9ea23

psztorc commented at 11:28 pm on February 10, 2018: contributor

I think I am now up to date on Luke’s requested changes and clarifications.

m7 op return update

This has been right in the code, but I kept forgetting to update the BIP.

485b1318bd

in bip-blind-merged-mining.mediawiki:40 in 485b1318bd outdated

35+
36+
37+Regular "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:
38+
39+# Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.)
40+# Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity).

luke-jr commented at 1:47 pm on May 30, 2018:

I’m not sure these are drawbacks. By eliminating them, you essentially turn all sidechain hashrate into a kind of decentralised Nicehash service. This can be catastrophic, since it essentially sells control to the highest bidder, which can easily be an attacker.

psztorc commented at 8:57 pm on May 30, 2018:

I’m not sure these are drawbacks.

The first is, I think. Some miners complained about Namecoin’s buggy software, and refused to use it – leading to suboptimal NMC hashrate, and disproportionate 2x-sha256 rewards (which some SC reviewers are strongly against). Also, if/when namecoin software crashed, it (very temporarily) took down the Bitcoin hashing network with it.

The second is really just a convenience. I suppose it is better for miners to “dogfood” (in a sense) their coinbases (they will be more loyal to Namecoin if they are paid in NMC). But in the sidechains case, they are being paid with BTC, and their ASICs have been designed mine BTC.

sells control to the highest bidder

This does give control over block ordering to the highest bidder. I am truly not sure what will happen as a result.

But first of all we are already in a world where control goes to the highest bidder – today, they must instead bid using illiquid currencies – ASIC equipment and electrical power. But if they win then they will have “control” (in the same limited sense that miners have control over block ordering today).

But, hashes/second has a time component, whereas the bidding in blind merged mining does not.

On the other hand, when Bitcoin has no block subsidy, an attacker can broadcast a string of “attack transactions” that pay extremely large fees, and thus induce miners to reorg the chain. It really comes down to the wealth generated by the chain, I think (whether it is a main- or side- chain).

in bip-blind-merged-mining.mediawiki:54 in 485b1318bd outdated

49+
50+As stated above, we have two goals: [1] create and monitor an alt-chain (defined only by a deterministic list of hashes), and [2] allow miners to "sell" the act of finding a sidechain block (through the use of a new extended serialization transaction type).
51+
52+=== Sidechain Critical Data ("Sidechain Mini-Header") ===
53+
54+Specifically, per side:block per side:chain, we track the following 35 bytes of information:

luke-jr commented at 1:49 pm on May 30, 2018:

This is a huge scalability regression for sidechains, which currently can be increased in number infinitely without adding more than a fixed 32 bytes to Bitcoin’s blocks.

psztorc commented at 9:01 pm on May 30, 2018:

Hmm, yes I think it is.

But it is intended to respond to the allegation that, in practice, miners would need to run a sidechain node. In that case, the scalability regression would be several orders of magnitude greater. Instead of 32 bytes in your example, it would be infinite bytes.

luke-jr commented at 9:14 pm on May 30, 2018:

The scalability regression affects not just miners, but all full nodes.

psztorc commented at 11:41 pm on June 2, 2018:

That is correct. It is part of the tradeoff required for trustless BMM.

One could still use the technique of BMM, without any code changes to Bitcoin. But it would involve some trust – likely, side:nodes would have to open (and fund) an account with pools. Side:nodes would then request that the pool find certain side:blocks (“blindly”) and the pool would then deduct some value (side:txn_fees - epsilon) from the node’s account.

in bip-blind-merged-mining.mediawiki:70 in 485b1318bd outdated

65+
66+==== Creating / Broadcasting This Data ====
67+
68+===== Creation =====
69+
70+By the time Blind Merged Mining can take place, the ChainIndex is globally known (it is the "Account Number" in D1 [see previous BIP], and "nSidechain" in the code). Each sidechain, when activated by soft fork, will take one of the 0-255 available indexes.

luke-jr commented at 1:49 pm on May 30, 2018:

Why would there only be 256 sidechains?

psztorc commented at 9:03 pm on May 30, 2018:

We only allocate one byte to identifying a sidechain.

But there can be sidechains-of-sidechains, so in practice there is no real limit.

in bip-blind-merged-mining.mediawiki:78 in 485b1318bd outdated

73+
74+The final item, prevBlockRef, is a little more complicated. It is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. In practice, this value will usually be zero. It will only be a value other than zero, in cases where invalid sidechain blocks have been mined, or when a side:node intentionally wants to orphan some side:blocks (if a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N ; in the block after that it will be back to zero).
75+
76+<img src="bip-blind-merged-mining/bmm-dots-examples.png?raw=true" align="middle"></img>
77+
78+Since the hashes themselves are already ordered by the mainchain, tracing the blockchain's path by index (prevBlockRef) will be the same as tracing it by identifying a list of hashes. In other words, the ordering given via each side:block's "prevBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ... if "prevSideHeaderHash is defined to be the sidechain's equivalent of the mainchain's "prevBlockHash". It will be possible to freely convert from one to the other. See M8 to learn more about how these hashes are requested by sidechain block creators to be included in the mainchain.

luke-jr commented at 1:51 pm on May 30, 2018:

What about side:blocks that do not meet the difficulty of a valid Bitcoin block (but still remain a valid sidechain block)?

psztorc commented at 9:07 pm on May 30, 2018:

Such a block would not be a found sidechain block. It would just be a candidate for the next block (perhaps), or else it would be some arbitrary collection of mempool data.

In BMM, a sidechain header meets its difficulty requirement if and only if the header is included in a mainchain Bitcoin block. That is the only way it can meet its “difficulty” requirement. This is a difference from regular merged mining.

in bip-blind-merged-mining.mediawiki:88 in 485b1318bd outdated

83+
84+Mainchain nodes are going to need this data later, so it must be easy to find. We will put it into the coinbase via OP RETURN.
85+
86+==== M7 -- "Blind-Mine the Sidechain(s)" ====
87+
88+Thus, (for n sidechains) we have a coinbase output with multiple OP_RETURNs (we've changed the tx-standardness policy to allow multiple OP_RETURNs):

luke-jr commented at 1:52 pm on May 30, 2018:

There is no tx-standardness policy for coinbases (it is a self-contradicting concept)… Nor are such matters of policy subject to BIPs - they are entirely up to implementations and/or individual node operators.

psztorc commented at 9:09 pm on May 30, 2018:

That may be so, but in practice many people have pointed out to me that I am “not allowed” to use multiple OP Returns. So it definitely interests some readers.

And we did in fact change the standardness policy.

Should we ensure that we have only changed the policy for coinbase txns only?

luke-jr commented at 9:15 pm on May 30, 2018:

Policy is about off-chain transaction acceptance. There is no policy for on-chain blocks - just consensus rules.

psztorc commented at 10:42 pm on May 30, 2018:

Ah, I see what you are saying.

I will try to find a way to clarify the sentence.

in bip-blind-merged-mining.mediawiki:4 in 485b1318bd outdated

0@@ -0,0 +1,341 @@
1+
2+<pre>
3+
4+    BIP: ????

luke-jr commented at 1:59 pm on May 30, 2018:

Let’s go with BIP 301.

psztorc commented at 9:10 pm on May 30, 2018:

Got it

luke-jr renamed this:
~~new bip - blind merged mining~~
BIP 301: Blind Merged Mining (Consensus layer)
on May 30, 2018

luke-jr commented at 6:27 am on March 29, 2019: member

Can we get this renamed and merged?

in bip-blind-merged-mining.mediawiki:129 in 485b1318bd outdated

124+
125+When new sidechains (or "hashrate escrows") are soft-forked into existence, a new column is added to D3 (to contain any BMMing that might be done on it).
126+
127+For each sidechain we also track the field "Blocks Atop". This is the number of side:blocks that are "on top" of the specified side:block. These might be regarded as "side:confirmations" (pseudo-confirmations that are specific to each sidechain).
128+
129+D3 also contains a column (not shown) for each sidechain containing "prevSideBlockHash". This value is is either derived from prevBlockRef; or else it is given explicitly (in which case it is the converse: prevBlockRef is derived from prevSideBlockHash).

rex4539 commented at 3:01 pm on April 3, 2019:

Typo: “This value is is either”

rex4539 changes_requested

improved image, with examples c90088ed81

number, shorten, clarify, link to working code bbcab029ea

in bip-blind-merged-mining.mediawiki:81 in bbcab029ea outdated

76+
77+sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally.
78+
79+prevBlockRef, is a little more complicated (next section). 
80+
81+To qualify for inclusion in a block, BMM requests are subject to the following reqirements:

rex4539 commented at 4:29 am on April 5, 2019:

Typo: “reqirements”

in bip-blind-merged-mining.mediawiki:176 in bbcab029ea outdated

171+
172+Now that we have described Requests, we can describe how they are accepted.
173+
174+=== BMM Accept ===
175+
176+For each BMM Request that a main:miner "accepts", main:miners must place an OP Return ouput into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)

rex4539 commented at 4:31 am on April 5, 2019:

Typo: “ouput”

in bip-blind-merged-mining.mediawiki:52 in bbcab029ea outdated

47+
48+To buy the right to find a sidechain block, users broadcast BMM Requests.
49+
50+Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message.
51+
52+Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how segwit handles witness data (the witness stack)).

rex4539 commented at 4:32 am on April 5, 2019:

segwit -> SegWit

in bip-blind-merged-mining.mediawiki:97 in bbcab029ea outdated

92+
93+Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other.
94+
95+===== Extended Serialization =====
96+
97+To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the segwit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).

rex4539 commented at 4:32 am on April 5, 2019:

segwit -> SegWit

rex4539 changes_requested

spellcheck 2d7093ba76

rex4539 approved

psztorc commented at 4:44 am on April 6, 2019: contributor

@luke-jr is it still ready to merge?

typo

the critical txn should start with "03", as it has version number 3

d69e368ce3

joshuajbouw commented at 2:24 am on July 8, 2019: none

Hey all, would love to see more progress on this, when merge?

luke-jr commented at 2:42 pm on July 23, 2019: member

@psztorc The file needs to be named bip-0301.mediawiki (and README updated)

Update dates/links to merge 329df0b836

Rename bip-blind-merged-mining.mediawiki to bip-0301.mediawiki 6ca33dc635

rename folder 1ff5d5d825

move images 42e96858d5

cleanup 1 69670c9da2

cleanup 2 4cd4e53752

psztorc commented at 4:30 pm on July 23, 2019: contributor

Ok it’s been renamed @luke-jr

fix spacing db117ef473

Add 301 Blind Merged Mining 542c66e6dd

in bip-0301.mediawiki:2 in 4cd4e53752 outdated

0@@ -0,0 +1,234 @@
1+<pre>
2+

luke-jr commented at 2:38 am on July 25, 2019:

Please check the preamble is formatted correctly. (There shouldn’t be blank lines here.)

README will also need to be updated.

psztorc commented at 6:59 am on July 26, 2019: contributor

Ok, spaces deleted and README updated

luke-jr merged this on Jul 26, 2019

luke-jr closed this on Jul 26, 2019

BIP 301: Blind Merged Mining (Consensus layer) #643