Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
OrganizationAdvent CalendarQiitadon (β)
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

ブラインドマージマイニング (コンセンサスレイヤー)

More than 1 year has passed since last update.

    BIP: 301
    レイヤー: コンセンサス (ソフトフォーク)
    タイトル: ブラインドマージマイニング (コンセンサスレイヤー)
    Author: Paul Sztorc 
    コメント要約: コメント無し
    コメント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は2つ以上のチェーンに跨った仕組みである。ここではビットコインのメインチェーンに関わる変更点のみに着目する。全体像についての説明は [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.






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



==== 即時無効化 ("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).


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.

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




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


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.

上の図: 3つのブロックチェーンが、それぞれ異なるブロック最大長(小さい数字)、再編成の履歴、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/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here].

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

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リクエスト ====

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:



    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.


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



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.


もしも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アウトプットを含めることができるようにしておく。)

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 ソースコードへのリンク].


(注: 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.)




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


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


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

Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away


No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
Help us understand the problem. What is going on with this article?