Bitcoin Core 0.13.0がリリースされた。
Bitcoin Core :: Bitcoin Core 0.13.0 Released!
Bitcoin Coreのブログより、主な新機能は↓
segregated witnessの準備
0.13.0で一番重要なコードの変更で、今後のソフトフォームに向けてsegwitのコードが含まれている。
※ このリリースではまだsegwitはアクティベートされない。実際にsegwitがアクティベートされた際、このリリースバージョンとは異なる挙動をするかもしれないので、segwitのアクティベーションを含むバージョンにアップデートすること。
segwitがアクティベートされる訳ではないけど、（一般的なBitcoinユーザにとってはあまり関係ないけど）segwitのコードがマージされた0.13.0を利用することで↓のようなメリットがある。
- segwitに簡単にアップグレード
0.13.0とsegwitがリリースされる次のバージョンのコードの差分は小さい。逆にBitcoin 0.12.1→0.13.0は様々なコードの変更が加わっているので、Bitcoin Coreに対して変更を加えているユーザにとっては、Bitcoin Core 0.13.0に対応しておけば、その後のsegwitのリリースバージョン（おそらく0.13.1）への更新は容易なものになる。 - segwitのテストがより簡単に
0.13.0は、mainnetではsegwitのコードを実行されないが、testnetやregtestではsegwitのコードが実行される。そのため開発者や管理者、テスターはその環境でsegwitを利用できる。 - 他の機能との完全な統合
このリリースに含まれる手数料のフィルタリングやCompact Blockのリレー、Child Pays For Parent、ARM Linux向けのオフィシャルバイナリといった他の機能がsegwitのコードと統合されている。segwitがアクティベートされるまで２ヶ月以上あるので、コミュニティレビューやテストによって潜在的な問題を解決するための時間が確保できる。
segwitの仕様についてはBIP-141,143,144,145にて定義されている↓
techmedia-think.hatenablog.com
techmedia-think.hatenablog.com
techmedia-think.hatenablog.com
bips/bip-0145.mediawiki at master · bitcoin/bips · GitHub
Compact Blockの導入
現状の仕様だとブロック中継時にブロック内の全トランザクションの情報も中継されるけど、中継先のノードが既にトランザクション情報を知っている場合、ブロック中継時にそのトランザクションのデータも全部送るというのはムダなので、それを削減して中継するデータ量を削減しようというのがBIP-152として提案されたCompact Block。
Compact Blockの細かい仕様については↓
techmedia-think.hatenablog.com
手数料のフィルタリング
ここ数年Bitcoin Coreのノードは、どの未confirmトランザクションを処理、リレー、メモリプールにに保存するか判断するのにminimum relay fee rate（最小中継手数料率）を使っている。各ノードはそれぞれminimum relay fee rateを持ち、受信したトランザクションの手数料率がそのリミットにかかると、自身のメモリプールに追加したり他のピアへリレーしたりしない。
0.13.0以前のBitcoin Coreでは、帯域幅の浪費になるため、ノード間でノードが使っているminimum fee rateを伝える仕組みはなかった。例えばアリスがボブにトランザクションを送る際、そのトランザクションの手数料率がボブが使っている手数料率より低かったとしてもトランザクションは送られる。この方法では、ボブはトランザクションの全てのデータをダウンロードした上で、初めてトランザクションの手数料率がリミットより低いことを知り、処理を停止する。これではアリスとボブ両者の帯域幅がムダに浪費されてしまう。
Bitcoin Core0.13.0ではP2Pプロトコルに新しく追加されたfeefilterメッセージをサポートする。このP2Pメッセージにより、ボブがアリスに現在自分が使っているminimum relay fee rateを伝えることができるようになり、アリスはボブのレートより低いレートのトランザクションをボブにリレーしないようになる。
feefilter messageの細かい仕様については↓
bips/bip-0133.mediawiki at master · bitcoin/bips · GitHub
BIP-32のHDウォレットのサポート
HDウォレットは１２個の単語から無限にキーペアを生成していく仕組みで。元の１２個の単語だけバックアップしておけば、そこから秘密鍵も復元できる。Bitcoin Coreでは今までHDウォレットをサポートしていなかったけど、今回のリリースからサポートすると。
正しくバックアップを取得するため、以下の点に注意しておくこと。
- 0.13.0以前のBitcoin Coreからバージョンアップする場合、各秘密鍵が個別に生成される古いスタイルのウォレットを使い続けることになる。このウォレットは毎回秘密鍵を生成しているわけではなく、事前に100個ずつ秘密鍵を作っている。各デフォルトのトランザクションは１つの秘密鍵を使うので、100トランザクション毎にウォレットのバックアップをする必要がある。
- 0.13.0で新規にウォレットを作成し、デフォルトの暗号化されていないウォレットから暗号化されたウォレットに変更する場合、HDウォレットが新しく生成される。まだ暗号化されていないウォレットに送られたBitcoinにアクセスできるが、ウォレットを再度バックアップしておくこと。
HDウォレットを使っているかどうかは”getwalletinfo”のRPCをすると分かる。実行した結果"masterkeyid"という項目が表示されていればHDウォレットを使っていて、無ければ使っていない。
HDウォレットをバックアップすれば、そのバックアップから秘密鍵を再生成できる。ただしそのバックアップからしかリカバリはできない。またバックアップ作成後に自分が送信・受信したトランザクションの説明などのデータをウォレットに追加している場合、その後HDウォレットのバックアップからリストアするとそれらの情報は消えてしまうので、定期的にウォレットのバックアップを行うよう推奨されている。
※ バックアップ作成後にウォレットにマニュアルでインポートした秘密鍵は、バックアップからはリカバリできないので、マニュアルで秘密鍵をインポートした際は新しくウォレットのバックアップを作成すること。
BIP-32はこちら↓
bips/bip-0032.mediawiki at master · bitcoin/bips · GitHub
マイニングする際のトランザクション選択ルールの改善（Child Pays For Parent）
0.13.0ではAncestor fee rate miningという新しいマイニング時のトランザクション選択方法が導入されている。マイナーはこの方法でどのトランザクションを次のブロックに入れるか選択する。この方法はマイナーとユーザ双方にとってメリットがある。
まず前提として、アリスがボブにBitcoinを送る場合、アリスがボブにBitcoinを送るトランザクションより、アリスがボブに送ろうとしているBitcoinをアリスが受け取るトランザクションの方が先にブロックチェーンに記録されている必要がある。言い換えると親トランザクションは子トランザクションより先にブロックチェーン上に現れる必要がある。
親トランザクションと子トランザクションが同じブロックに含まれているケースがあるが、その場合でも親トランザクションは子トランザクションより先に記載されている必要がある。
ここでマイナーのインセンティブを考えると、親トランザクションは手数料が低いためになかなかブロックに取り込まれない状態でも、子トランザクションの手数料が高ければマイナーは子トランザクションの手数料を得るため、まだconfirmされていない親トランザクションと子トランザクションを一緒にブロックに入れようとするインセンティブが働く。
- マイナーのメリット
マイナーにとってはバイトあたりより高い手数料が得られる方が良いので、ancestor fee rate miningでその優先順位を判断できるのはメリットになる。 - ユーザのメリット 親トランザクションの手数料が低くなかなかconfrimされない場合に、子トランザクションで高い手数料を設定することでマイナーに親トランザクションと子トランザクションの両方をブロックに含めるよう促すことができる。
このインセンティブの概念はよくChild Pays For Parent（CPFP）と呼ばれる。一番シンプルなバージョンでは、子トランザクションと親トランザクション、トータルでバイトあたりの手数料が次のブロックに含めるのに充分な手数料があるかどうか判定する。
ancestor fee rate miningの肝は、親と子の２つのトランザクションが同じユーザによって作られる必要がないところにある。例えばボブがアリスがボブに送ったトランザクションのconfrimを待っている場合でも、ボブは独自に子トランザクションを作成しマイナーに子トランザクションと親トランザクションを一緒にconfirmするよう仕向けることができる。
ただancestor fee rate miningは、手数料の高い子トランザクションがあるからといって、低手数料のトランザクションがマイニングされることが保証される訳ではない。特に、ほとんどのマイナーやノードはKB単位の最小手数料（レートはノードによって異なる）を支払っていないトランザクションを無視するため、親トランザクションがそのリミットより低い手数料を設定していたら、子トランザクションがどんなに高い手数料を設定していてもマイニングされることは無い。
ARM上のLinux向けのオフィシャルビルド
ARM向けに↓の32bitと64bitのオフィシャルのBitcoin Coreバイナリが新しく提供される。
- bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries for the most common 32-bit ARM architecture.
- bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries for the most common 64-bit ARM architecture.
所感
- segwitはアクティベートされたわけではないけど、オフィシャルリリースされた0.13.0でtestnetやregtest環境でsegwitがテストできるので、双方向Payment ChannelのOpening Channelとか実際にテストできそう。
- BIP-142はステータスが現在Deferredになっており141とは一緒にデプロイされないみたい。
- まだよく見てないBIP（145や133とか）が既にリリースされてるので、近々ちゃんと仕様を理解しておきたい。
- Bitcoin Coreのウォレットって秘密鍵は１００個単位で事前に生成されてたのか。
- Ancestor fee rate miningが有効なケースって、0 confirmで子トランザクション作るケースってことよね。malleabilityの問題を考えるとsegwitのアクティベートが終わってからリリースした方が良かったんじゃ？と思ったけど結局親はどちらかしかconfirmされないから問題ないのか。
- Ancestor fee rate miningは、意味的には親の手数料を子が肩代わりできるようになったということで、手数料自体が節約できる訳ではない。
- 正しいバイナリかどうか確認する方法として、Gitianプロセスという複数人でバイナリをビルドし署名するプロセスとかあるのね。
