BitcoinABCクライアントのインストールとチェーン同期

2018-11-21

Bitcoin Cash(BCH)の、2018年2回目のハードフォークが11月15日に予定されているが、今回はbitcoin-abc(以下、”ABC”)とbitcoin-sv(以下、”SV”)で異なるアップデート内容が発表されている。実際にはクライアントはこの2つではなく他にもあるのだが、今回はこの2つのアプリケーションで大きく意見が割れている。

ABCとSVの違い

具体的な経緯や内容はBCHNewsさんの以下の記事にまとまっていたので、詳細を知りたい場合は読んでみてください。

ABCとSVで相違している部分を、思想とかは抜きにプログラム的な違いだけを抜き出して比較すると以下のようになる。また、今のところABCもSVもリプレイプロテクションを実装しない予定。

bitcoin-abcbitcoin-sv
ブロックサイズ1ブロックのサイズ32MB128MB
OP_CHECKDATASIG任意のデータに対する署名をスクリプト内で検証できるようにするOPコード
CTORブロックにトランザクションを格納する際の順序にルールを設ける
OP_MULaにbを掛ける
OP_LSHIFTaを左にbビットシフトし符号を保持する
OP_RSHIFTaを右にbビットシフトし符号を保持する
OP_INVERT入力のすべてのビットを反転する。
OPコード数上限スクリプトごとのOPコード数の上限201個上限なし

ここに挙げているもの以外の仕様は過去までのチェーンと同様であることを前提とすると、ABCにのみ実装されている仕様が含まれるブロックが採掘された場合、SVは拒否をするし逆も同じ。まあ、拒否というよりは自身が認識できないブロックとして取り込むことができない。

例えば、”OP_CHECKDATASIG”を使ったトランザクションを含むブロックは、ABCを採用しているウォレットで作成可能で、ABCを採用しているマイナーがブロック採掘時に取り込むが、SVを採用しているマイナーはブロック採掘時に取り込まない。また、上記のトランザクションを含むブロックを伝播した場合、ABCを採用しているマイナーはそのブロックを取り込みマイニングを行うが、SVを採用しているマイナーはそのブロックを無視してマイニングを続ける。

ABCでもSVでも取り込めるようなトランザクションに関しては、両方のマイナーがブロックに取り込む可能性がある。1ブロックあたりに取り込まれるトランザクションは1つではないので、「ABC、SVのどちらの独自仕様も含まないかから大丈夫でしょ」という訳にはいかない。自分以外の誰かが、どちらかしか取り込めない仕様でトランザクションを作成し、そのトランザクションがブロックに取り込まれたところから、同一チェーン内で分岐(フォーク)する。という感じ。

長いなw

1度でもフォークが発生すればABCもSVも無効なブロックは無視してマイニングを続けるので、そのままチェーンが伸びていく事になる。利用者側の立場で見ると、送金をしてブロックに取り込まれ、” 確認数 1 “と表示されたはずなのに、次のブロックで ” 確認数 0″になってしまった。と思ったら、いきなり ” 確認数 10 “と表示された…のに、しばらくしたらまた ” 確認数 0 “になってしまった。のようなことが起こると思う。

ということでbitcoin-abcをインストールして同期してみる

何が「ということ」かは置いておいてだ、なんかとりあえずノード側でどう見えるのかとか気になってくるわけだよね。どちらにしろ、同期まで時間もかかると思うので、いまの内にフルノードを作っておいてみようと思うんだ。

そもそも直前でリプレイプロテクションが入るかもしれないし、フルノード作らなくても、誰かが可視化できるようなサイトを作るかもしれないし、何よりフルノードを作ったところでそれを観察できるだけの技術がないかもしれないけど、とりあえず作ってみようと思いましたまる

bitcoin-abcのインストール

以前、BitcoinCoreをインストールした時もソースコードからmakeしているので、今回も同じようにソースコードからmakeします。

まずはソースコードを保存しておくフォルダに移動し、git cloneでソースコードをダウンロード。

$ git clone https://github.com/Bitcoin-ABC/bitcoin-abc.git

ダウンロードしたフォルダに移動。

$ cd bitcoin-abc/

makeの前に…

makeを実行する前に、必要なライブラリなどはUNIX BUILD NOTES等を参考に準備しましょう。もし、BitcoinCoreのmakeを実施したことがあるなら、不足分は以下のライブラリだけだと思います。

$ sudo apt-get install libdb-dev libdb++-dev

makeを実行してインストールする。

$ ./autogen.sh
$ ./configure --without-gui --program-suffix=-abc
$ make -j2
$ sudo make install

configureのオプション “–without-gui” はGUIなし。”–program-suffix=-abc” はインストールプログラムの後ろに “-abc” を付与する。

僕の環境には、すでにCoreのbitcoind、bitcoin-cli、bitcoin-txが存在するので、どうしようかとオプション見ていたら、サフィックス付けられることを発見したので、サフィックスで見分けることにした。
(以後、”bitcoind-abc” のように “-abc” が付いているのは僕の環境のみです。)

installしないならサフィックスも必要ないですね。というか最初はCoreとABCを同時に起動しようと思っていたんだけど、ネットワークの関係で同時起動はできなかったので、インストールまでやらなくても良かったよ…

bitcoin.confを準備

デフォルトではホームディレクトリ直下の “.bitcoin” にconfファイルを配置する必要がある。

$ mkdir $HOME/.bitcoin
$ touch $HOME/.bitcoin/bitcoin.conf
$ vim $HOME/.bitcoin/bitcoin.conf

# 以下を記述
datadir=/media/hdd/.bitcoin-abc
rpcuser=hoge
rpcpassword=hogehoge
txindex=1

“datadir”は指定しなければconfファイルと同じ場所にデータが格納されるだけなので、不要であれば外してください。”txindex”はトランザクションの全インデックスを取得するかの設定で、指定した場合は同期に時間がかかるため、目的に応じて設定してください。

チェーンの同期をする

confファイルが準備できたらあとは起動するだけ。

$ bitcoind-abc -daemon

止めるときは以下のコマンドで止める。

$ bitcoin-cli-abc stop

※上で記載した通り”-abc”は僕の環境では必要なので付いてます

これで2、3日放っておけばチェーンが同期されるだろう。

書きながら思ったけど、途中までは同じチェーン使っていたのだから、Coreのデータフォルダをコピーしてチェーン同期すれば早く終わるのだろうか?

今度時間ができたら試してみようかな(。・ω・)ノ゙

チェーンの同期が終わったので追記

途中でchecksumが一致しないとかいうエラーが発生して、何度やりなおしても同じ場所でアプリが落ちてしまうので途中でインデックスの再構築をやっています。

インデックス再構築の開始からの時間になっちゃうけど
 開始:2018/11/10 7:49:19
 終了:2018/11/12 11:51:20
およそ52時間ぐらいかかった。

BitcoinCoreを同期した時は、50時間だったけどこの時は “txindex=1” オプションを付けていなかったので、単純な比較にはならないので参考程度だな。

今回も同期の過程をグラフ化してみた。前回と比べてもちょっと低空飛行で進んでいるから、やっぱり”txindex=1″ オプションを付けると時間がかかるんだろうな。最後の方で急激に上昇しているのはだいたいBTCからBCHが分岐したブロックあたりでした。なんか、システム開発時の進捗グラフみたいになってるw

ちなみにBTCチェーンからBCHがフォークしたブロック番号は 478558。BCHとして最初のブロックは 478559 です。それと、ブロック番号 478577 〜 478582 の間で、急激な難易度調整があったみたいだね。(実際のブロックをみてみた)

まあ、でもチェーン同期にかかる時間は、ブロックの採掘難易度ではなくブロックに含まれているトランザクション数だろうな。つまりBCHの方がトランザクションは少ないということか。途中で同期のペースが横ばいになっているのは2017年12月頃で、BTCのスケーリング問題が顕著になり、BCHのトランザクション量が増えた頃と一致する。

ついでに同期が終わったところでBTCとBCHの最新ブロックも比較してみた。

個人的にはとても面白い結果だった。チェーンの長さはBCHの方が全然長いけど、difficultyとchainwork(その時点までにかかった仕事の総量)は、BTCの方が全然高い。

上のtwitterでは書き忘れていたけど、同期後のデータサイズを記載しておく。
 BTC:224GiB
 BCH:163GiB
これならSV用に同期フォルダをコピーしても、僕の環境ではまだ容量に問題はなさそう。

だから何だということはないけどw

なかなか面白いなとは思う。BCHはビッグブロッグではあるものの、トランザクションはそんなに発生していない。2020年の半減期にはまだ時間があるけど、トランザクションが大量に発生しないことには、BTCからフォークした意味がなくなってしまうと思うんだよね。

BCH頑張れー!さらに分岐しそうだけど!

追記:makeしないでAWS上にサクッとノード作る方法も試したー