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

spellcheck

Browse Source
This commit is contained in:
Paul Sztorc 2019-04-05 10:02:24 -07:00 committed by GitHub
parent bbcab029ea
commit 2d7093ba76
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bip-blind-merged-mining.mediawiki
View File

@ -1,4 +1,3 @@
<pre>
BIP: 301
@ -49,7 +48,7 @@ To buy the right to find a sidechain block, users broadcast BMM Requests.
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.
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)).
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)).
==== Immediate Expiration ("Fill-or-Kill") ====
@ -78,7 +77,7 @@ sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The
prevBlockRef, is a little more complicated (next section).
To qualify for inclusion in a block, BMM requests are subject to the following reqirements:
To qualify for inclusion in a block, BMM requests are subject to the following requirements:
# Requests must match a corresponding "BMM Accept" (see last section of BIP).
# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include.
@ -94,7 +93,7 @@ Above: Three blockchains, with different max length (small number), reorganizati
===== Extended Serialization =====
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).
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).
<img src="bip-blind-merged-mining/witness-vs-critical.png?raw=true" align="middle"></img>
@ -173,7 +172,7 @@ Now that we have described Requests, we can describe how they are accepted.
=== BMM Accept ===
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.)
For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)
The following data is required in the "accept" OP_RETURN output:
1-byte - OP_RETURN (0x6a)
@ -233,4 +232,3 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam
==Copyright==
This BIP is licensed under the BSD 2-clause license.