

    BIP: 301
    レイヤー: コンセンサス (ソフトフォーク)
    タイトル: ブラインドマージマイニング (コンセンサスレイヤー)
    Author: Paul Sztorc 
            CryptAxe 
    コメント要約: コメント無し
    コメントURI: https://github.com/bitcoin/bips/wiki/Comments:BIP-301
    ステータス: ドラフト
    タイプ: 標準化方針
    作成日: 2017-10-24
    ライセンス: BSD-2-Clause

==概要==

Blind Merged Mining (BMM) is a way of mining optional extension blocks (ie, "asymmetric sidechains"). BMM produces weak 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.

BMM actually is a process that spans two or more chains. Here we focus on the modifications to mainchain Bitcoin. For an explanation of the "whole picture", please see [http://www.truthcoin.info/blog/blind-merged-mining/ this post].

Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block.

ブラインドマージマイニング(BMM)は、オプションで拡張ブロック（非対称サイドチェーン）をマイニングする方法である。BMMはどんなルールのセットに対しても、そのルールに関してブロックが有効であるという弱い保証を生成できる。その上、マイナーはそのルールセットにおけるブロックの検証をする必要がない。

BMMは２つ以上のチェーンに跨った仕組みである。ここではビットコインのメインチェーンに関わる変更点のみに着目する。全体像についての説明は [http://www.truthcoin.info/blog/blind-merged-mining/ この投稿]を見てほしい。

ここでの最終目標は、サイドチェーンのブロックを採掘する行為を、無与信下でメインチェーンのマイナーが「競売にかけられる」ようにすることである。

==動機==

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:

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.)

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).

BMM addresses both shortcomings.

普通の「マージマイニング」(MM)はマイナーがハッシュ計算を他のチェーン（例えばNamecoin）を保護するために再利用することができる仕組みである。しかし、これまでのMMには2つの問題点がある。

マイナーが他のチェーンのフルノードを稼働させる必要がある。（これはなぜなら、マイナーは追加コスト無しでブロックを作成できる一方で、マイナーが正しいブロックを作って自分に報酬支払いをしなけれならないからである。それゆえ、マイナーはまず「正当な」ブロックを作って、それからMMをする必要がある。）

マイナーは他のチェーンにおいて報酬を受取、BTCの普通のメインチェーンでは受け取らない。例えば、NamecoinをマージマイニングするマイナーはNMCを報酬として稼ぐ（そして、マイナーはBTCを電気代の支払いに当てる前にNMCをBTCに換金しなければならない）。

BMMはこれらの２つの欠点を改善するものである。

==規格==

Note: This document uses the notation side:* and main:* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain counterpart. We also use "Simon" to refer to a Sidechain Full Node, and "Mary" to refer to a mainchain miner.

注意: このドキュメントはside:*やmain:*といった記法を曖昧な語句(ブロック、ノード、チェーンなど)の前に置いて、メインチェーンとサイドチェーンで異なることを指すために使う。また、「サイモン」をサイドチェーンのフルノード、「メアリー」をメインチェーンのマイナーを示すために使う。

=== BMM リクエスト ===

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)).

サイドチェーンのブロックを採掘する権利を買うために、ユーザーはBMMリクエストをブロードキャストする。
BMMリクエストは２つのモードがある。一つはライトニングネットワークを要求しないが、即時無効化のために新しい要件がある(以下参照)。もうひとつは即時期限切れの性質をライトニングネットワークそれ自体から受け継いでいるが、異なる、あるいはサイズの大きなメッセージのために追加で準備が必要である。

どちらの形態も、ある重要データが、トランザクションの含まれるブロックのコインベースに含まれている必要がある（BMMアクセプトを参照）。オンチェーン（非ライトニング）の形態のために、新しい拡張シリアル化トランザクション（SegWitがウィットネスデータ(ウィットネススタック)を扱う方法に似ている）を作成した。。

==== 即時無効化 ("Fill-or-Kill") ====

We would like to make special guarantees to the counterparties of this transaction. Specifically, instead of Simon making a "payment" to Mary, we prefer that Simon give Mary an "offer" (which she can either accept or decline).

Crucially, we want Simon to safely make many offers to several different Mary's, in realtime (ie, quickly and off-chain). However, we ultimately want only one offer to be accepted, at most. In other words, we want Simon's offers to immediately expire. If only one offer can become a bona fide transaction, then Simon will feel comfortable making multiple offers all day long. Because all of the Simons are making many offers, the Marys collectively gain access to a large set of offers to choose from.

このトランザクションのカウンターパーティに特別な約束をさせたい。とりわけ、サイモンがメアリーに支払いをする代わりに、サイモンがメアリーに「提案」(サイドチェーンのブロックをどれに決定するかの選択)を出せるようにするのが好ましい（メアリーは提案を受理しても拒否してもよい。）

重要なこととして、我々は安全に、リアルタイムで（オフチェーンで素早く）、サイモンからメアリーにいくつもの提案をしてもらいたい。しかし、我々は最終的には最大でも一つの提案だけが受理されてほしい。言い換えれば、我々はサイモンの提案が「即時に無効化」されてほしい。もしもたった一つだけの提案が正しいトランザクションになれるなら、サイモンはいくらでも提案をすることができる。サイモンがたくさんの提案を出すことができるならば、メアリーはより多くの提案の中から品定めして選択することができる。

==== オンチェーン BMM リクエスト ====

OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation.

オンチェーンBMMリクエスト (オンチェーンBMMR)はライトニングネットワークを必要としないが、検証のために新しい要件がある。

===== 構造 =====

The following data is required:

以下のデータが必要である。


    32-bytes  - h* sideHeaderHash
    ?~?-bytes - critical data extended serialization
        3-bytes - 0x00bf00 identifying bytes
        1-byte  - nSidechain
        2-bytes - prevSideBlockRef
        4-bytes - prevMainHeaderBytes

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.

sideHeaderHashはside:chainのヘッダハッシュである。(side:nodesがマイナーとなってside:blocks/headersを作る) identifyingバイトはマジックナンバーで固定されている。nSidechainはどのサイドチェーンについてBMMを行うのか特定する。BMMが行われるときにはすでにこの番号が広く知られているものとする。

prevBlockRef, is a little more complicated (next section).

prevBlockRefは少しややこしい(次のセクション)。

To qualify for inclusion in a block, BMM requests are subject to the following requirements:

ブロックに含まれる条件として、オンチェーンBMMリクエストは以下の要件を満たす必要がある。

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.

The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about).

リクエストは対応する「BMMアクセプト」と一致しなければならない(BIPの最終セクションを参照)

一つのmain:blockの中には、サイドチェーン一つにつき一つだけのリクエストを含めることができる。言い換えれば、もしも700人のユーザがサイドチェーン#4のためのBMMリクエストを発行したとして、main:minerがそのうちブロックに含めるのは最大一つなのでどれかを選ばなければならない。

4バイトのprevMainHeaderBytesは、一つ前のmain:blockheaderの終端4バイトと一致しなければならない。このようにすることで、サイモンのトランザクションは、サイモンの見ているメインチェーンのブロック履歴の中において現在のブロックでのみ有効であることになる(したがって、現在のサイモンが見ているサイドチェーンのブロック履歴においても現在のブロックのみで有効になる)。

===== prevBlockRef =====

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.

prevBlockRef(注:prevSideBlockRef?)は現在のside:blockの親となるブロックを見つけるために、現在のside:chainの直近ブロックから「スキップ」する数を記録する整数である。この値は、サイドチェーンが再編成しない限り(または、無効なサイドチェーンブロックをスキップしてブロックを作り直さない限り)0である。もしもside:nodeが直近Nブロックを孤立させたい場合、最新ブロックにおけるprevBlockRefの値はNになる。その次のブロックでは、値は0に戻る。

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.

上の図: ３つのブロックチェーンが、それぞれ異なるブロック最大長(小さい数字)、再編成の履歴、prevBlockRefの数字(ブロックの下の大きい数字)を持っている。それぞれのside:blockのprevSideBlockRefによって与えられる順序付けは、それぞれのside:blockのprevSideHeaderHashによる順序付けと同型になる(prevSideHeaderHashはサイドチェーンにおいてメインチェーンのprevBlockHashに等しい)。それぞれの順序付けの間では相互に変換が可能である。

===== 拡張シリアル化 =====

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).

トランザクションレベルで新しい要求を課すために、ダミーのvinとflagを用いたトリックをSegWit形式のトランザクションと同様に利用する。トランザクションを取り込んだブロックが、サイドチェーンの重要なデータを含むそのトランザクションのすべての要求を満たしていなければ、トランザクションは無効となる。SegWitにおいては、この拡張データはSegWit署名スタックであり、拡張要件は署名の場所と有効性になる。サイドチェーンBMMの重要なデータトランザクションにおいては、この拡張データは(nSidechain, h*)のペアである。このペアは上記の2つの要件(注:サイドチェーンは一つのみ、BMMアクセプトとの一致?)とmain:blocknumberを満たす必要がある。さらにmain:blocknumberは上記の3つ目の要件(注:prevMainHeaderBytes?)を満たす必要がある。

Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#txD4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here].

上図: 通常のtx、SegWitのtx、BMMリクエストのtxを示す。このSegWitトランザクションは [http://srv1.yogh.io/#txD4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 ここ]で見ることができる。

These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned.

これらの異なるトランザクションではmempoolでの振る舞いがそれぞれ少し異なっており、可能であれば別のmempoolで処理されるべきである。これらのトランザクションは受信された後すぐに検証され、有効であればブロックへ取り込むべきかを評価することになる。もしもリクエストされたtxが宣言したブロックに取り込めない（すなわち、すでに宣言したブロックが最新の先頭のブロックではなくなってしまっている場合）、このリクエストは破棄される。実際、main:blockが一つでも新しく発見された場合、新しいリクエストtxが新しい先頭ブロックに応じて作成されることになるので、このBMM専用mempoolの中のトランザクションはすべて破棄してしまって構わない（ブロック再編成が起こりうるとしても同様である）。(注:再編成を自分で起こして、BMMのmempool内の別のtxを使う可能性はあるのでは？) BMMのmempoolの中ではtxは取り込まれるか破棄されるかのどちらかであり、txの再評価は不要である。同じtxを再評価するためにスキャンする必要もない。

Interestingly, these payments will always be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks).

興味深いことに、BMMのリクエストの支払いは常にnon-main:minersからmain:minersに向けて発せられることになる。したがって、マイニングを行わないフルノードでは、BMM専用のmempoolを用意する必要は全くない。マイニングを行わないノードはブロックが見つかるのを待ち、トランザクションの検証だけを行えばよい。これらのトランザクションは株取引市場における立会場のようなものである（対照的に、普通のビットコインのtxは小切手のようなものである）。(注:競りや競売のようなイメージ)

==== ライトニングBMMリクエスト ====

Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today.

LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data:

ライトニングBMMリクエスト(ライトニングBMMR)ではサイモンがメアリーとの間にLNのチャネルパスを開設していなければならない。これは今日の未発達なネットワークでは実用的ではなく、不可能かもしれない。

LNのトランザクションはセトルメントtxがいつメインチェーンにブロードキャストされるのか不明であるため、prevSideBlockRefを利用することができない。代わりに、prevSideBlockHashを使う必要がある。そのためには以下の同様なデータが必要である。

   
    4-bytes - Message header (0xD0520C6E)   
    1-byte - sidechain number
    32-bytes  - h* side:block hash  
    32-bytes  - prevSideBlockHash

Notice that, in OnChain BMMRs, Simon could reuse the same h* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include zero txns. So, we will never know what the Requests were, or how many had an effect on anything.

Therefore, Simon will need to ensure that he '''gives each Mary a different h*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h*).

With a unique h* per Mary (or, more precisely, per channel), and at most 1 h* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time.

That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary.

オンチェーンBMMRにおいてはサイモンは同じh*を何回でも再利用することができた。これは、オンチェーンBMMRではサイドチェーン一つにつきリクエストは一つまでしかmain:blockに含むことができないという制約があったからである。しかし、LNではそのような制約を課すことはできない。なぜならば、ここでの最終目標はメインチェーンでtxを一度も発行せずにすませることだからである。よって、我々は過去にどのようなリクエストが存在していたのか、実際に何がメインチェーンに取り込まれたのかといった情報を知らないということになる。

したがって、サイモンは'''メアリーに毎回異なる h* を渡さなければならない'''。サイモンにとって、side:blockの作成時にside:nonceを調整することで異なるブロックを作り、したがって毎回異なるh*を作ることは簡単である。

メアリーに固有の(言い換えればメアリーとのチャネルごとに固有の)h*を用意し、サイドチェーン一つあたり最大でも一つのh*がブロックに入るのであれば、サイモンは高々一回だけしか課金されないということを確認できることになる。

これはややこしいかもしれない。以下に例を用意した。サイモンは13BTCからスタートし、メアリーは40BTCからスタートする。side:blockのトランザクション手数料は現在7.1BTCであり、サイモンは0.1BTCを自分に割り当て、7BTCをメアリーに支払うことにする。

We start with (I):


    Simon 13 in, Mary 40 in ; 53 in total
        Simon's version [signed by Mary]
            13 ; to Simon if TimeLock=over; OR to Mary if SimonSig
            40 ; to Mary
        Mary's version [signed by Simon]
            40 ; to me if TimeLock=over; OR to Simon if MarySig
            13 ; to Simon

最初の状態 (I):


    サイモン 13, メアリー 40 ; 合計 53
        サイモンの側 [メアリーにより署名]
            13 ; 時間切れでサイモンに支払い; または サイモンの署名があればメアリーに支払い
            40 ; メアリーへの支払い
        メアリーの側 [サイモンにより署名]
            40 ; 時間切れでメアリーに支払い; または メアリーの署名があればサイモンに支払い
            13 ; サイモンへの支払い

And both parties move, from there to (II):


    Simon 13 in, Mary 40 in ; 53 in total
        Simon's version [signed by Mary]
            6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
            40 ; to Mary
            7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over
        Mary's version [signed by Simon]
            40 ; to Mary if TimeLock=over; OR to Simon if MarySig
            6 ; to Simon
            7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over

両者はここから次の状態に移る (II):


    サイモン 13, メアリー 40 ; 合計 53
        サイモンの側 [メアリーにより署名]
            6 ; 時間切れでサイモンに支払い; または サイモンの署名があればメアリーに支払い
            40 ; メアリーに支払い
            7 ; BMMRデータ要件を満たせばメアリーに支払い; または 時間切れでサイモンに支払い
        メアリーの側 [サイモンにより署名]
            40 ; 時間切れでメアリーに支払い; または メアリーの署名があればサイモンに支払い
            6 ; サイモンに支払い
            7 ; BMMRデータ要件を満たせばメアリーに支払い; または 時間切れでサイモンに支払い

From here, if the h* side:block in question is BMMed, they can proceed to (III):


    Simon 13 in, Mary 40 in ; 53 in total
        Simon's version [signed by Mary]
            6 ; to Simon if TimeLock=over; OR to Mary if SimonSig
            47 ; to Mary
        Mary's version [signed by Simon]
            47 ; to me if TimeLock=over; OR to Simon if MarySig
            6 ; to Simon

リクエストされたside:blockのh*が実際にBMMで取り込まれたとき次の状態に移行する (III):


    サイモン 13, メアリー 40 ; 合計 53
        サイモンの側 [メアリーにより署名]
            6 ; 時間切れでサイモンに支払い; または サイモンの署名があればメアリーに支払い
            47 ; メアリーに支払い
        メアリーの側 [サイモンにより署名]
            47 ; 時間切れでメアリーに支払い; または メアリーの署名があればサイモンに支払い
            6 ; サイモンに支払い

If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it.

If the h* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h*, trying again with new side:block in the next main:block).

Now that we have described Requests, we can describe how they are accepted.

もしもサイモンが直ちに移行すれば、メアリーがこのside:blockの上にさらにブロックを追加するインセンティブはなくなる。もしもサイモンのside:blockが孤立した場合、サイモンは7BTCを失うことになる。サイモンは安全を優先してside:blocksが(例えば)100ブロック経過するのを待つ(すなわち、(III)の状態に移行する前に待つ)か、または孤立ブロックでBTCを失うリスクを取りつつチャネルを直ちに(III)の状態に移行することもできる。

もしもh* side:blockがBMMで採掘されなければ、(II)と(III)の状態は互いに等しい(注: (II)と(I)では?)。サイモンとメアリーは協力して再び(I)を作成することもできるし、h*の異なる新しい(II)の状態へ移行することもできる(次のmain:blockで新しいside:blockの取り込みを試みる)。

ここまでリクエストについて説明した。次に、リクエストがどのように受理されるのか説明する。

=== BMM アクセプト ===

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)
1-byte - Push the following 36 bytes (0x24)
4-bytes - Message header (0xD3407053)
32-bytes - h*
~5-bytes - BMM identifier bytes

[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code].

If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.)

main:minerが「受理」するそれぞれのBMMリクエストに対して、main:minerはmain:coinbaseトランザクションにOP Returnアウトプットを作成する必要がある。(txの標準ポリシーをアップグレードして複数のOP_RETURNアウトプットを含めることができるようにしておく。)

以下のデータがOP_RETURNアウトプットによって「受理」するために必要である。
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-bytes - Message header (0xD3407053)
32-bytes - h*
~5-bytes - BMM identifier bytes

[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 ソースコードへのリンク].

もしこのようなOP_RETURNアウトプットが存在しなければ、BMMリクエストは受理されたことにはならない(そしてもし受理されていないのであれば、main:blockには含まれていないと言えるはずである)。

(注: BMM identifier bytesは不明)

==後方互換性==

As a soft fork, older software will continue to operate without modification. As stated above, BMM asks nodes to track a set of ordered hashes, and to allow miners to "sell" the act of finding a sidechain block. Non-upgraded nodes will notice that this activity (specifically: data in coinbases, and new txns that have OP Returns and interesting message headers) is now taking place, but they will not understand any of it. Much like P2SH or a new OP Code, these old users will not 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 money here all happen to be miners. So there is less reason than ever to expect compatibility problems.)

この変更はソフトフォークなので、古いソフトウェアは変更なしにそのまま運用可能である。上で述べられたように、BMMを利用するノードは順序付けられたハッシュ値の集合を追跡することで、メインチェーンのマイナーがサイドチェーンのブロックを発見する行為を「競売にかける」ことができる。アップグレードしていないノードもこの様子を観測することになる（コインベースのデータとメッセージヘッダのついたOP_Returnトランザクションが見える）。しかし、古いノードはこれらを解釈することはできない。P2SHや新しいオペコードのように、古いソフトウェアのユーザはこのタイプの支払いを受けることはないので、このフォークで直接影響を受けることはない。

(実際のところ、ここで資金を受け取るプレイヤーはマイナーだけなので、後方互換性に関する問題は少なくてすむはずである。)

==デプロイ==

This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and using bit 4.

このBIPはBIP9のバージョンビット4を利用し「blindmm」という名前でデプロイされる。


// Deployment of Drivechains (BIPX, BIPY)
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4;
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020.
consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021.

==リファレンス実装==

こちらを参照: https://github.com/DriveNetTESTDRIVE/DriveNet

興味があればサイドチェーンの例はこちら: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

==参照==

==謝辞==

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.

==Copyright==

This BIP is licensed under the BSD 2-clause license.