diff options
| author | Paul Sztorc <psztorc01@gmail.com> | 2019-07-23 09:14:33 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-07-23 09:14:33 -0700 |
| commit | 329df0b8368e04c92780cb039f1c5fb9f0cd386c (patch) | |
| tree | 10a500724e770389cd67aeb2a1fe03ffa7706925 | |
| parent | d69e368ce3ef402e57f34ed40bf61508355ffa9d (diff) | |
| download | bips-329df0b8368e04c92780cb039f1c5fb9f0cd386c.tar.xz | |
Update dates/links to merge
| -rw-r--r-- | bip-blind-merged-mining.mediawiki | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki index 7f29f06..1a6e999 100644 --- a/bip-blind-merged-mining.mediawiki +++ b/bip-blind-merged-mining.mediawiki @@ -9,7 +9,7 @@ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-301 Status: Draft Type: Standards Track - Created: 2017-10-24 + Created: 2019-07-23 License: BSD-2-Clause </pre> @@ -87,7 +87,7 @@ To qualify for inclusion in a block, BMM requests are subject to the following r prevBlockRef 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. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain 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. -<img src="bip-blind-merged-mining/bmm-dots-examples.png?raw=true" align="middle"></img> +<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img> 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. @@ -95,7 +95,7 @@ Above: Three blockchains, with different max length (small number), reorganizati 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> +<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img> Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here]. |