ビットコインの情報サイトの運営者ブログ

サイトには掲載していない仮想通貨に関する時事的な情報や個人的な感想など。中級者以上向け。

ビットコインのフルノードとは?定義と役割・メリット

今更と言えば今更な内容ですが、最近シングルボードコンピュータを使ってビットコインのフルノードを立ち上げ始めたので、そのレポート記事を書く前に一本解説記事を書いておきます。

定義と役割

定義というのは変わるもので、「フルノード」の定義についてもあれこれ追加の条件を付けくわえる人はいますが、最も一般的には「すべてのブロックとトランザクションをダウンロードし検証するノード」と言えると思います。ちなみにビットコインネットワークに接続しているコンピュータのことは総称して「ノード」と呼ばれます。

普段ウォレットで使うような、いわゆる軽量型クライアントはSPVクライアント(正確には軽量型の中にはサーバー・クライアント型と呼ばれるものもあり、さらにサーバー・クライアント型のものでもSPV型の検証を行っているソフトもあるので、細かく説明するとややこしくなります)とも呼ばれフルノードとは区別されます。こちらは、過去のすべてのブロック・トランザクションをダウンロード・検証するわけではなく、起動後すぐにウォレットとして使用できるため、ほとんどの人はフルノードのウォレットを利用することはありません。

フルノードとマイナー

よく混同されるのがフルノードとマイナーです。マイナーはブロックやトランザクションの検証も行いますが、主目的はブロックを生成して(nonceを探索)採掘報酬を得ることです。一方フルノードの役割は、ブロックやトランザクションを検証し、各ブロック・トランザクションがビットコインの基本ルールを守っていることを確認し、有効なもののみを他のノードやマイナーに伝達する役割があります。

マイナーも無効なトランザクションなどをブロックに含めてしまったり、無効なブロックを生成してしまってはせっかく採掘に成功しても報酬が無駄になってしまうので、フルノードと同じくすべてのブロックとトランザクションの検証を行うのが基本となりますが、ソフトフォークの記事で少し書いたように、SPVマイニングと呼ばれるようなすべて検証せずに採掘を行うような方法もあるので、「フルノードの一部をマイナーと呼ぶ」と単純に言うとやや語弊がある気がします。

悪意のあるマイナーによるビットコインへの攻撃はしばしば話題にあがりますが、その時に重要な防御策となるのがフルノードの存在です。単一のマイナー・マイニングプールが多くのハッシュレートを確保することによる51%攻撃では、何もないところからお金を生成したり採掘報酬を勝手に増やしたりして、ビットコインネットワークのルールを破るようなことは通常できず、攻撃の範囲が限られますが、それは善良なフルノードが存在するという前提での話です。

軽量型のウォレットノードはいちいちブロックの正当性を検証しないので、悪意のあるマイナーが生成したトランザクションを有効なものとしてほとんど無条件に受け入れてしまうことがあります。実際は多くの善意のフルノードの存在により、不正なトランザクション・ブロックはフルノードから弾かれ、軽量型のウォレットはフルノードから情報を受け取るので、悪意のあるマイナーからのトランザクションを直接受け取るようなことはなく攻撃が防がれることになります。

アーカイブノード(Archival Node)と剪定ノード(Pruning Node)

かつては、フルノードの説明として「すべてのブロックチェーン、取引履歴を保存するノード」という表現が使われることがしばしばあり、当時は間違いではなかったのですが、現在ではやや不十分な説明になってしまっています。

それは、Bitcoin Core 0.11.0へのバージョンアップにより、剪定モード(Pruning Mode)というものが実装されたためです。ブロックチェーンのサイズは現在では100GBを超えるため、フルノードの運用は大きな負担となっています。その負担を少しでも減らすため、過去の不要なトランザクション・ブロックを削除して保存しないようにしようという試みが剪定モードです。剪定モードでは、最初は全てのブロック・トランザクションをダウンロード・検証しますが、不要になったものは削除し、最終的にはすべてのUTXOと直近のブロックのみを残します。二重支払いがない有効な取引かどうかは、ブロックチェーン全てを検証するまでもなくUTXOだけを検証すればよい話なので、いらないデータは削除してしまおうというわけです。

この剪定モードを採用しているノードは剪定ノード(Pruning Node)と呼ばれますが、一度は全てのブロック・トランザクションのダウンロード・検証を行うので、一般的には「フルノード」に含められます。

対して、従来のように過去のデータを削除せずすべてのブロックチェーンを保存するノードは、アーカイブノード(Archival Node)と呼ばれます。最新の取引の有効性を確認するのは、剪定ノードだけで十分ですが、剪定ノードも最初はすべてのブロックをダウンロードする必要があります。当然他の剪定ノードはもう古いデータを削除してしまっているため、他のノードからダウンロードしなくてはなりません。そのときデータを提供するのがアーカイブノードです。剪定ノードもアーカイブノードもどちらもフルノードであり、直近の取引の検証という意味では違いがありませんが、アーカイブノードもビットコインネットワークのためには重要な存在と言えます。

フルノードを運用するメリット

ビットコインはフルノードを運用するインセンティブがない!とよく言われ、確かにそれに反対する人は少ないでしょうが、全くゼロかというとそういうわけでもないので、簡単に説明してみたいと思います。

セキュリティとプライバシー

前半で説明したように、軽量型のSPVウォレットは、ブロックチェーン全体やブロック自体、トランザクションそのものの正当性を自分では検証できず無条件に正しいものと信じるようになっています。ただし、軽量型であっても現実的には一つではなく複数のフルノードからの情報を比較・検証するので、単一のノードから送信された不正なブロックは実際上は弾かれることになります。たまたま接続したいずれのフルノードもビットコインのルールに違反する不正なブロックを有効なものとして伝達していた場合は、防ぐことができませんが、現状そこまでフルノード数は減少していないので、リスクは無視できるほど小さいものです。

フルノードを利用していれば自分ですべてのブロックチェーンを検証できるので、他のノードをそもそも信用する必要がありません。もちろん前述のように、不正なブロックチェーンを有効と認識してしまうような現実的なリスクはかなり少ないと思われるので、気分以外に普通のユーザーがフルノードウォレットをセキュリティ面で利用するメリットは、フルノードの運用コストと比較するとほぼゼロと言えるでしょう。

もう一点がプライバシー面です。軽量型のウォレットは実装によって多少の差はあるものの、基本的には特定の複数または単一のフルノードに自分のアドレス情報などを伝達しないといけないので、そのノードにIPアドレスとアドレス情報などが結び付けられてしまいプライバシーがダダ漏れになってしまう可能性があります。フルノードは自分が作成したトランザクションだけではなく他のノードから受け取ったトランザクションも同時に伝達するので、他人のトランザクションと紛れてどれが自分のトランザクションかわからなくなりますが、軽量型のSPVノードは自分が作成したトランザクションしか送信しないと考えると、プライバシーのリスクの差が分かりやすいと思います。

とはいえ通常のユーザーであれば、そもそもフルノード側もいちいちそれが誰のトランザクションなのかなんて気にしないと思いますし実質的に気持ちの問題以外のリスクはないと思います。

攻撃のターゲットになりやすい多額のBTCを保有している資産家の人や有名人なんかはプライバシー面が大きなメリットになる場合もあります。

セキュリティ・プライバシー面を考えてフルノードを運用するには?

実際にセキュリティやプライバシーの観点からウォレットにフルノードを利用したい!となった場合、いろいろな困難が付きまといます。

まず、ブロックチェーンが常に同期状態でないといけないため、コンピュータを常時起動しておく必要があります(1日放置しただけで検証に結構な時間がかかります。)。さらに問題となるのが、自分が自宅サーバーなりVPSとして運用している特定のフルノードに直接接続できるウォレットがかなり少ないということです。

フルノードをインストールしているコンピュータに直接ウォレットをインストールするのはいろいろと不便ですし、他のPCのウォレットからであったり、スマホのウォレットからであったり、外出先であっても自分のフルノードに接続できると便利でしょう。しかし、知る限り現状では特定のIPを指定してノード(Bitcoin Core)に接続、通信が可能なのは、PC用のmSIGNA、Android用のBitcoin Wallet(Schildbath wallet)のみです。

例えばCopayであったりElectrumであったりは専用のサーバーを別に立ち上げなければなりませんし、そもそも特定のサーバーに接続できないSPVウォレットも多く存在します。

ウォレット用途でフルノードの運用を考える場合は、そこらへんをよく調べておいたほうが良いかもしれません。

ネットワークへの貢献

もう一つのメリットがネットワークの貢献です。とはいえこちらも気分の問題なのでメリットといえるかどうかは怪しいところです。

現状、ビットコインのノード数はかなりの減少傾向にあるとはいえ、問題となる領域には達しておらずまだまだ安全な状況だと思います。とはいえ危険領域になってからでは遅いので今から貢献しておいてもいいかもしれません。

実際フルノードを運用するとなったときいくつかの選択肢があります。

外部からのノード接続を受け入れるか(ポート開放するか)

通常、フルノードを運用するにはポートを開ける必要はありません。ただし、ポートが空いていないと外部からのノード接続は受け入れないので、自分が一方通行的に適当なノードと接続するだけで、ネットワークへの貢献としては小さくなります(ネットワーク帯域を消費するだけの存在なのでむしろ害であると主張する人もいます。)。

ただしノードとの接続数が多くなればなるほどメモリの消費量などが多くなるので、使用するコンピュータによってはスペック上難しい場合もあります。

ちなみによくビットコインノード数として公開されているデータはポート解放されているノードの数だけであり、実際に運用されているフルノードはもっと多いと考えられます(そもそもポート解放されていないと、自分から接続しに行かない限り、第三者からはそのコンピュータがノードであると認識・接続できないので取得しようがありません。)。

アーカイブノードか剪定ノードか

前述のようにブロックチェーンをすべて保存するかしないか、を選ぶことが可能です。アーカイブノードのほうが役割は多いですが、剪定ノードでも十分フルノードとしての役割を果たせるので、コストを考えて選ぶと良いでしょう。

VPS・クラウドか自宅ノードか

ネットワークへの貢献を考えるなら自宅ノードのほうが良いでしょう。VPSのノードがいくら増えたところで、VPSはあくまでも仮想サーバーでしかなく分散されていないので、攻撃などにより同一のVPSを利用しているノードが同時に影響を受けるリスクがあります。また、例えばAmazon AWSがビットコインノード利用禁止!と掲げた場合には一斉にAWS上のノードは中止を強いられます。

実際の運用コストや安定性を考える場合にはVPSのほうがいいかもしれません。AWSなんかはノードを運用しようと思うとコストがかさんでしまいますが、海外の格安VPSを利用すればかなり安く運用することができます。

自宅ノードではインターネット回線の帯域制限があったり、コンピュータの故障リスクなども大きいので、ビットコイン関連のサービス運用に利用するにはVPSやクラウドを利用するのが安定だと思います。

終わりに

ということで、割と本気を出してアーカイブノード&自宅ノードの運用をはじめましたが、100GBを超えるブロックチェーンの同期にあと1日~2日ぐらいかかりそうなので、同期が終わった後にまた記事を書きたいと思います。

【独自トークン】初配当を実施しました。(独自トークンプラットフォームの配当機能について)

当サイト・ブログの独自トークンJPBITPTを保有している方向けに各プラットフォーム上の通貨で50%分の配当を実施しました。元々記念トークン、実験トークンという位置づけですが、1年近く経っていて保有者向けに何もお返しできていなかったので、1月のサイトからの収入が多かったこともあっての配当です。

記念トークンという位置づけは変えないつもりでこれが最後かもしれないので、今後の配当は期待しないでください。

 

せっかく、配当を行ったので簡単に「配当機能」についてまとめておきます。独自トークンの配当機能といっても各プラットフォームで違いがあり、現在ウォレットに機能として実装されているのがCounterpartyとNxtのみです。

ただし、配当機能というのは、要するにブロックチェーンから各アドレス・アカウントが保有するトークン量を読み取り、それに合わせてコインを配布する、というだけのものなので、プロトコルなどのバックエンド・根本的なシステムの問題ではなく、基本的にはウォレットやその他送金ツールなどのフロントエンドの機能です(トランザクションのタイプとして「配当」というものをプロトコル実装して、配当時だけ特別に送金手数料を安くする、といった機能は考えられますが・・・)。

そのため、プログラムが書ける人はAPIなどを利用すれば、自力で割と簡単に配当ツールを作れるのではないかと思います。今回利用したBitShares、NEM、Ethereumは、現在のところウォレットに機能が実装されていませんが、トークン保有者が少数だったので、手間を考えて手動ですべて送ってしまいました。

Ethereumなんかは、特に自由にプログラムが書けるので、毎月トークン保有者に自動的に配当を送るとか希望者が特定のアカウントにメッセージを送ることで自主的に配当をもらうことができるとか、いろんなかたちの実装が考えられます。

ということで、配当ということだけを考えた場合は、現状でもツールを作ろうと思えばどれでも作れるので、真面目なビジネス用途のトークンはどのプラットフォームを使おうと構わないのですが、非技術者のお遊び程度であれば、現状はCounterpartyとNxtの二択ということになると思います。とはいえ、実際は利用者が多いことが何よりも重要なので、特定のプラットフォームに思い入れがない限りCounterparty一択になってしまいますが。

利用者数という面を考えるとNEMもよさそうですが、作成手数料(約5500XEM)を考えると現状はちょっとハードルが高い感じがします。NEMに関してはmijinとかcatapultとかプライベート方面を先に攻めていっている印象なので、そこがある程度終わってからNEM自体の環境整備(分散型取引所の実装とか)に期待というところでしょうか。

BitSharesの近況

Ethereumはなんかよくハードフォークしてるし、NEMはApostille出してCatapultっていうのを開発中らしいし、Nxtはとりあえず2.0(Ardor)待ちだし、CounterpartyはEVM(Ethereum Virtual Machine)をtestnetに実装したりpicopaymentsなんてものもあったな・・・。

そういえばBitSharesってどうなってるの?ということで、BTSの最新情報を発信をしている人が皆無なので現状をまとめておきたいと思います。

開発者が交代

BitSharesの開発者といえば兼創業者のbytemaster(Daniel Larimer)でしたが、昨年のはじめ頃から分散型RedditことSteemの開発に専念するようになり、BitSharesの開発からは完全に手を引きました。

彼はcryptonomex社という会社を立ち上げ、そのメンバーと共にBitSharesの開発を行っていましたが、cryptonomex社自体も開発を行わなくなり、現在は過去の開発チームのごく一部の人とBitShares Munichというドイツの会社が引き続き開発を行っています。

オープンソースで分散型なので、元々の開発チームが開発を完全に止めてしまってもネットワークが止まることはありませんし引き続き他の人が開発を行えるというのは強みといえるでしょう。

実際の開発状況は?

とはいえ、引き続き開発を行っているBitShares Munich社もウォレットなど主にフロントエンドの開発を行っており、バックエンドのプロトコルの改良等はほとんど手付かずの状態です。昨年の3月を最後にハードフォークを要するようなプロトコルのアップデートは行われていません。

フロントエンド自体に関しても、モバイルウォレットをリリースしたのは良いものの、セキュリティ上のバグにより数か月間停止状態になっていたり、bytemasterが最後に置き土産としてプロトコルに実装したStealth Transactionという匿名送金の機能がいまだにGUIウォレット上で実装されず・・・、というようにやや開発力には不安がある状況です。

暗号通貨の開発チームは、○○に支配されているとか分散されていないとかいった批判を受けることが良くありますが、小さいプロジェクトは個人・企業がある種強権的に開発を推し進めないと、開発がうまくすすまないという側面はあるような気がします。

ネットワークの状況

バックエンドの開発はあまり進んでいないものの、BitShares自体がまだまだ未完成なものかと言うと、分散型取引所としての完成度は十分高いと思われ、ネットワーク自体のトラブル等も特になくかなり安定した状態が続いています。価格はどん底まで落ちていますが、新規アカウントの作成数やトランザクション数は安定しており、分散型取引所の約定数は増加傾向にあります。

f:id:jpbitcoin:20170131201226p:plain

(画像はcryptofresh.comより)

関連プロジェクト

正直、BitSharesにもまだまだ課題があり、増加傾向にあるとはいえ分散型取引所の取引量がなかなか増えないことや、大きなアピールポイントであるはずの価格連動型トークンのSmartcoinsが実質的にほとんど利用されていないことなどに対する対策の提案も過去には活発になされていました。現在その開発も議論も停滞状態にあるのは大きなマイナスであることは間違いありませんが、現状を見るとBitSharesそのものよりも他の関連プロジェクトに引っ張り上げられるかたちに期待するしかないのかなあ、という印象です。

OpenLedger

BitSharesそのものとよく混同されやすいOpenLedger(過去記事参照)。同社が掲げているような分散型取引所、というよりはただのIOU発行企業なのですが、やはりBitSharesの強みはIOUではなくSmartcoinsのほうなので、ややインパクトに欠ける感じです。

あまり最近の状況を追い切れていないのでなんともいえないのですが、同社の分散型取引所ビジネスというよりはBitTeaserのようなさらにサイドのプロジェクトに期待したいです。

個人的にはICO連発、無駄?なトークン連発であまりいい印象がありませんが、継続してサービス提供してくれているので、APIサーバー、faucetサーバーとしての役割でBitSharesのインフラの安定には大きな役割を果たしているところです。

Peerplays

ブロックチェーンベースのゲームプラットフォーム。ブロックチェーン自体は全く別に立ち上げられていますが、BitSharesと同じGrapheneというプラットフォームを元にしているため、基本的システムからウォレットGUIまでほとんど一緒です。現在はじゃんけんゲームで相手に勝つと所持金(掛け金?)を貰えるような簡単なゲームだけtestnetに実装されています。

昨年一度ICOを行っており、今年近いうちにまた二度目のクラウドファンディング(ICO?)を行う予定のようです。BitShares関連の中では期待が高いように思えますが、過去の同様の関連プロジェクトは、DAC Play(旧BitShares Play)やMUSE(Peertracks、旧BitShares Music)をはじめとして、お金を集めたのにも関わらず全てのプロジェクトがほぼ音信不通で近況不明状態なので、コミュニティ外からの評判は良くなく去年のICOもあまり成功していません。

Steem

去年立ち上がった分散型SNSで時価総額3位に上り詰めたことで話題になりました。

f:id:jpbitcoin:20170131204638p:plain

(画像はsteemb.comより)

ユーザー数等の良いデータがあまり見つからなかったのですが、去年8月から見るとアクティブユーザー数は大きく減ったものの、11月頃からは下げ止まって現在はほとんど成長なしで横ばいという状況のようです。複雑なインフレの仕組みはとりあえず置いといて解決したと仮定したとしても、少なくともなかなか暗号通貨に対するリテラシーのある人でないと使う気にはならないと思うので、暗号通貨コミュニティ内で十分知られるようになった後の成長は、暗号通貨自体の一般層への普及がすすまないと厳しそうな感じです。

開発に関しては独自路線を進んでいるため(Graphene外の部分での機能拡張、新たにGraphene 2.0の開発を発表、Graphene 2.0はBitSharesに適用するメリットがどこまであるか不明等・・・)、Peerplaysほどは密接に結びついていませんが、SteemはBitSharesと同じくGrapheneを元にはしているので、Steemが成功すればBitSharesにもいい影響を与えられる可能性があります。

ビットコインの取引手数料の仕様を詳しくまとめてみる

ネットワークの混雑でビットコインの取引手数料について改めて考えることが多いので、仕様についてまとめることにしました。手数料周りの仕様は意外と頻繁に変わっており、改めて調べるまで個人的に勘違いというか知識が古いものもありました。この記事の情報も後から見返すと古い可能性がありますのでご注意ください。

取引手数料の基本

まずは基本的事項について再確認。ビットコインの取引手数料は、取引の承認者であるマイナー(採掘者)に支払われ、高ければ高いほど早く確認(承認)される傾向にあります。マイナーからみると報酬を多くもらえる取引を優先して処理したほうが儲かるので当然の傾向です。また、手数料の大小はBTCの送信額に対する割合ではなくトランザクション(取引データ)のサイズあたりの割合(BTC/バイト)により判断されます。これも、データとして見た時にビットコインの送信額は関係ないので(10BTCであろうが1BTCであろうがデータの大きさが変わらなければ取引データの通信コストは変わりません)、当然の傾向です。

トランザクションのサイズの決定方法

取引手数料を決めるにはまずデータのサイズを求める必要があります。トランザクションには署名データが含まれ、署名は作成するまでサイズが分からないので、正確なサイズを算出することはできませんが、以下の式でおおよそのサイズを求めることができます。単位はバイト(byte)です。
148*input数+34*output数+10

このようにinputの数とoutputの数に依存します。inputとoutputについてはUTXOの概念を知っていれば分かるかと思います(以前の記事参照)。outputは単純に送金先のアドレス数と等しいです。inputの場合はUTXOの数になるので、送金元が一つのアドレスだけであってもUTXOが何個もある場合があります。

最もよくあるinputが一つでoutputが二つ(送金相手のアドレスだけではなく自分のお釣り用アドレスにも送金する場合がほとんど)のトランザクションのサイズは、
148*1+34*2+10=226バイト
となります。特に例は貼りませんが、実際にinputが1つでoutputが2つのトランザクションのサイズをブロックエクスプローラーで見ると、ほぼすべてが226バイトから1~2バイト程度のサイズに収まっていることがわかります。

ちなみにトランザクションサイズの算出方法を調べると
180*input+34*output+10
という式がよく見られますが、これはinputの中に含まれている公開鍵の形式が非圧縮型(uncompressed key)であるためです。間違いというわけではありませんが、現在はほぼすべてのウォレットが非圧縮型より32バイト小さい圧縮型の鍵(compressed key)を利用しているので、inputのサイズは基本的に148程度と考えるのが良いと思います。

これらの算出式は通常のビットコインアドレスからの送金なので、マルチシグネチャアドレスやCounterpartyを利用する場合は通常よりもサイズがやや大きくなります。CounterpartyはOP_RETURNという上限40バイトのデータが付加されるだけなのでそこまで大きくはなりませんが、2of3のよくあるマルチシグの場合は倍近くになります(ただしCounterpartyではトークンの送付時に非常に少額のBTCを送らなければならないので、頻繁にトークン受信を行っているような場合はUTXO・小銭の数が増えinputの数も増えて合計サイズが大きくなる傾向にあります。)。
採用されない可能性も十分ありそうなので省略しますが、Segwitが実装されるともちろん上記の計算式は変わってきます。

最適な取引手数料の予測

取引手数料は、未確認のトランザクションの総サイズ(メモリプールの総サイズ)などに影響を受けてマイナーが決めるものなので単純な計算によって正確に求めることは難しいです。幸いなことに以下のような計算サイトがあるので、参考にすると良いでしょう。複雑なので具体的な算出方法はよく理解できていませんが、最近のハッシュレート、トランザクションサイズ、手数料の大きさなどによって算出しているようです。
https://bitcoinfees.21.co/
https://bitcoinfees.github.io/
上のサイトが有名で、グラフの緑部分以上の手数料を払うと遅延なし(10分で確認)で済みます。この記事を書いている時点では、90satoshi/byte=0.0000009BTC/byteがベストのようです。先ほど計算したように1input2outputの典型的なトランザクションの場合は、226*0.0000009=0.0002034BTC支払えば良いということになります。

あくまでも226バイトはほぼ最小のサイズであり、実際はinputの数が多かったりします。現在の平均のトランザクションサイズ約500バイトで計算すると500*0.0000009=0.00045BTCとなります。
f:id:jpbitcoin:20170118221003p:plain
https://tradeblock.com/bitcoin/historical/1d-f-tsize_per_avg-01101

基本的にこれらの作業は全部ウォレット側がやってくれますし(一部手数料予測の性能の悪いウォレットもあるようですが)、そもそもUTXOが見れなかったりトランザクションのサイズ表示ができないウォレットが多いので、普通のユーザーはあまり気にする必要はなく自力で計算したくてもできないことが多いのですが、なかなか確認されない取引があったら、ブロックエクスプローラーでその取引のサイズと手数料を確認して先の手数料予測サイトの最適手数料と照らし合わせると確認が遅い理由が納得できるかもしれません。

取引確認の優先度

現在、ビットコインの取引の確認の優先度は単純に手数料によって決定されています。以前は、priorityというパラメータも考慮されており、priorityの中には以下のようにcoin ageというコイン・UTXOの古さ(最後に使用されたときからの未使用期間の長さ)やコイン量があるので、古いコインほど残高が多いほど早く確認されやすいという面もありましたが、このpriorityは現在では実質的にほとんど使われていません。
priority=(coin\ amount*coin\ age)/transaction\ size

ちなみに、Bitcoin Core(Qt)0.6までは取引確認の優先度は完全にこのpriorityに依存しており、送信額が多ければ逆に手数料を支払わなくて良いという一見不思議な仕組み(送信額が少ないほど要求手数料が少なくなるとネットワークへのスパム攻撃が容易になるので理にはかなっています)でした。

バージョン0.7からは現在の手数料が大きければ大きいほど優先して取引される仕様が導入され、一定額以下の手数料(現在のBitcoin Coreの規定の設定は0.00001BTC/byte)の取引のみを対象としてpriorityが考慮されるようになりました。priorityが一定以上になれば手数料無料でも送信できるという仕様です。

ネットワーク全体のトランザクション数の増加により、バージョン0.12からはBitcoin Coreでのマイニングの際の既定の設定として全くpriorityが考慮されないようになってしまい、単純に手数料のみから優先度が決定されるようになりました。同時に手数料が0.00001BTC/byte以下の取引が承認される見込みはほとんどゼロとなりました。
他にデータソースが見つからなかったのでtwitterからの引用になってしまいますが、以前は可能とされていた手数料無料の取引は2016年には実際にほとんど絶滅した状態になっているようです。

現在もトランザクションのリレー(ノードからノードへの伝達)においてはpriorityが使用され、priorityが十分高ければ手数料がなくてもリレーされる設定が規定となっていますが、Coreの開発チームではpriorityの完全廃止が議論されており、現在のところ0.14ではpriorityに基づくリレーの仕様も規定でなくなり、0.15ではpriorityの概念が完全になくなる予定となっています。

ちなみにこのpriorityというのは、基本的にはビットコインのユーザー数やトランザクション数を増加させるための一つの戦略であり、手数料無料でも送信できることでビットコインの利用数を増やそうという目的のもとに利用されていたものでした。現在はトランザクションが多すぎるほどになっており、手数料無料の取引をわざわざブロックに入れてくれるマイナーがいなくなったために廃止の方向になったということです。

最終的にはマイナーが自由にどの取引を確認するか決められる

今までpriorityなど取引確認の優先度の「仕様」を説明してきましたが、これらはすべて未確認状態の取引の話なので、実際にはマイナーが恣意的にどの取引を確認するかを決められます。Bitcoin Coreではデフォルトの数値が設定されているだけなので、数値を変えるだけですぐに最低の取引手数料を0.00001BTC/byteから引き上げることもできますし、今は使わない設定になっているpriorityを復活させて手数料無料の取引を受け入れることもできます。
Bitcoin Coreでは、priority以外にも「fee delta」という、取引の優先度をマイナーが自由に変えられる架空の取引手数料の概念も実装されています。特定の取引IDを対象にしてfee deltaの数値に大きな架空の手数料を入力すれば、あたかも高手数料の取引として実際の手数料に関係なく最優先で確認することが可能というわけです。そのため、マイナーが自分や友人が送信する取引は手数料無料でも優先して承認・確認するというのは普通に行われ得ることだと考えられます。
究極的に言えば、マイナーが特定のアドレスをブラックリスト化したりホワイトリスト化したりして、取引を制限することも可能です。ただし1%でもすべての取引を受け入れるマイナーがいれば100ブロックに1回は対象の取引が確認されることになるので、単一のマイナーが100%支配するという現実離れした事態が起こらない限り、完全にコントロールすることはできません。

ビットコイン価格を計量分析して各種価格データとの相関関係を考察してみた

最近の話題といえばやはりビットコインの価格でしょう。価格予想でも書ければ面白いのですが、トレーダーでも投資家でもない私としては皆目見当がつかないので、中々探しても見つからないビットコインの価格データの計量分析を自分でやってみることにしました。
なお、どうしても専門用語を多く使ってしまっていますが、すべて説明していると1記事では収まらないのでかなり省略しています。またあくまで素人が趣味・独学の範囲で行っているものですので分析の誤り等にはご容赦ください。

使用するデータ

今回使用するデータとして、BTCJPY、BTCUSD、BTCCNY、USDJPY、EURUSD、USDCNY、TOPIX(日本株)、S&P 500(アメリカ株)、SSEC(中国株)、金、原油の11種を選びました。
為替、株、商品市場のそれぞれ代表的なものです。日経平均やNYダウでもいいのですが、より市場全体を代表する指標ということでTOPIXやS&P500を選んでいます。
期間としては、短期間での1000%以上の大暴騰からのMt.Gox事件&中国規制のダブルパンチで暴落した2013年末から2014年にかけての価格の急変動の影響を避けるために、2015年から2016年末までの二年間を対象としています。また、ビットコイン以外は休日の取引が行われていなかったりして365日分のデータが存在せず、曜日の価格変動への影響等もあると考えられ、補正が面倒なので日次ではなく週次データを用いています。

BTCと他指標との相関を調べる

計量分析では、まず単体(BTC価格レート自体)の分析を行うのも基本の一つですが、それもやっているととんでもなく長くなってしまうので、今回はとりあえず他指標との相関を見てみます。
今回はRという統計分析用のフリーソフトを使用しました。補助的にエクセルも使用しています。
まずはこんな感じで変数xに予めデータを用意しておきます。

> head(x)
  BTCJPY   BTCUSD   BTCCNY USDJPY EURUSD  USDCNY   TOPIX  S.P500     SSEC   GOLD   OIL
1  32650 272.9486 1680.950 119.62 1.1931 6.13712 1401.09 2020.58 3350.519 1204.0 50.04
2  31612 267.0873 1657.472 118.36 1.1831 6.11451 1380.58 2028.26 3229.316 1232.8 46.07
3  25151 213.9783 1305.910 117.54 1.1604 6.12366 1372.41 2019.42 3116.351 1276.9 48.69
4  32207 271.9491 1676.265 118.43 1.1238 6.15241 1402.08 2057.09 3383.182 1279.4 45.15
5  27937 237.5409 1485.608 117.61 1.1336 6.16393 1408.75 2020.85 3128.300 1276.2 49.57
6  26115 220.1743 1368.693 118.61 1.1321 6.14044 1424.92 2046.74 3095.124 1240.8 52.86

つづいてこれらのデータから相関係数を算出します。
f:id:jpbitcoin:20170111000603p:plain
量が多いので見づらいかもしれませんが、上(左)から三つはすべてBTC価格です。一般的に相関係数は0.7以上あれば強い相関があるとされます。BTC価格同士でほぼ1という非常に強い相関があるのは当然として、他に相関が高いのはUSDJPY(-0.66~-0.76)やUSDCNY(0.91~0.92)でしょうか。では、USDJPYとUSDCNYとの関係について見ていきましょう。・・・とはなりません。
実は時系列データの相関をみるとき、見せかけの相関といって実際は全く何の関係もないデータであっても相関を示す確率が高いためです。つまり相関係数に何の意味もない可能性があります。

安易に相関係数が計算されているのはいろんなサイトでよく見ますがちょっと寄り道して検証してみましょう。
まずはランダムな週次データ(2年間計104個)を適当に5つ生成し、BTCUSDとの相関係数を見てみます。

> random1=cumsum(rnorm(104))
> random2=cumsum(rnorm(104))
> random3=cumsum(rnorm(104))
> random4=cumsum(rnorm(104))
> random5=cumsum(rnorm(104))
> BTCUSDvrandoms=data.frame(BTCUSD,random1,random2,random3,random4,random5)
> chart.Correlation(BTCUSDvrandoms)

f:id:jpbitcoin:20170111002445p:plain
なんと2番目のランダムデータと5番目のランダムデータは0.8台という非常に強い相関を示してしまいました。ランダムに生成したデータであっても5個中2個も強い相関を示してしまうとは信頼性が低いと言えるのではないでしょうか。

> plot(BTCUSD,type="l")
> par(new=T)
> plot(random2,type="l",col="blue")
> par(new=T)
> plot(random5,type="l",col="red")

f:id:jpbitcoin:20170111003759p:plain
試しに相関が高かったデータをプロットしてみるとなんとなくトレンドが似ている、あるいは逆なことが分かります(黒がBTCUSD、青が二番目のランダムデータ、赤が五番目のランダムデータ)。そもそもビットコインに関わらず価格データというのは大体右上がりか右下がりのトレンドを形成するチャートになっており、トレンドが似ているというだけで相関係数が高くなってしまうので、安易に相関係数を計算して参考にしてしまうのは良くないのです。
(ただし、同じBTC価格で見れば非常に相関が高かったように、参考にならない場面が全くないわけではありません。)

さらなるデータとして、相関係数の経時変化を見てみましょう。先ほど計算した相関係数の期間は2015年から2016年の二年間の合計ですが、今回は1年間の相関係数の推移を計算しました。
f:id:jpbitcoin:20170111004609p:plain
なんだか常に相関が高いUSDCNYは置いといて、時期によって全く異なることがわかります。例えば、原油(OIL)を見ると2016年5月頃は-0.8と非常に負の相関が強かったものの、半年後には+0.8と完全に逆転しており最低でも相関係数の変化を見ないと誤った結論を出してしまうことになります。(そもそも原油がビットコインと相関があるとは考えづらいのにもかかわらず、かなり高い相関を示すのがおかしいといえます。)

これを見ると、最近言われているようにCNYの価格との相関はありそうな気がしてきますが、この相関はここ二年で顕著に見られるだけで2013年までさかのぼると全く相関はなくなります。(もちろん相関というのは動的に変化するものなので、実際に過去相関がなかったのに最近になって相関が出てきたということかもしれません。)
f:id:jpbitcoin:20170111005418p:plain

では普通に計算したのがダメならどうしたらよいのかというと、一つ前のデータとの差分=変化率の相関を見れば良いのです。変化率を見るというのは、要するに価格Aが上がったとき(下がったとき)、価格Bに対してどのような影響があるか、ということです。どちらも同時に上がったり下がったりすることが多いほど相関が高いということになります。
ということで、差分の相関係数を見てみましょう。単純に引き算をすると価格水準によって差が出てしまう(例えば60000円のものが60円下がるのと100円のものが60円下がるのでは全く異なります)ので変化率、それも対数変化率で見ていくことにします。

> x.diff=diff(log(x))
> head(x.diff)
       BTCJPY      BTCUSD      BTCCNY       USDJPY       EURUSD        USDCNY        TOPIX       S.P500
1 -0.03230806 -0.02170793 -0.01406574 -0.010589224 -0.008416850 -0.0036909416 -0.014746804  0.003793710
2 -0.22863914 -0.22170096 -0.23839325 -0.006952126 -0.019373339  0.0014953219 -0.005935382 -0.004367924
3  0.24728616  0.23974031  0.24966799  0.007543368 -0.032048974  0.0046839180  0.021388530  0.018482042
4 -0.14223185 -0.13527510 -0.12074379 -0.006948003  0.008682610  0.0018706862  0.004745938 -0.017774202
5 -0.06744211 -0.07592031 -0.08196783  0.008466734 -0.001324094 -0.0038181603  0.011412885  0.012730075
6  0.05776665  0.05902720  0.06128803 -0.001265449  0.002646438 -0.0009564148  0.023930277  0.024254700
         SSEC         GOLD          OIL
1 -0.03684495  0.023638658 -0.082660707
2 -0.03560753  0.035147260  0.055311691
3  0.08215386  0.001955953 -0.075483390
4 -0.07832691 -0.002504306  0.093395532
5 -0.01066176 -0.028130580  0.064261097
6  0.04028698 -0.011591748 -0.001514578
> chart.Correlation(x.diff)

f:id:jpbitcoin:20170111012042p:plain
先ほどとはうって変わって全般的に相関が低くなり、ビットコインに関してはどの価格データとも相関がないという結果になりました。このように差分をとると、ランダムなデータが間違って高い相関を示す確率は非常に低いと言えることがわかります。

f:id:jpbitcoin:20170111012414p:plain
相関係数の経時変化を見てもすべての期間で最大0.3程度となりました。この結果は昨年にArk Investという米投資会社とCoinbaseが共同で出した、ビットコインは他のアセットとの相関が低い新しいタイプのアセットであるというレポートの結果と一致します。同レポートでは相関係数の数字も出ていますが、2011年からスタートして年間の相関係数の変化を計算しており、その中で見られた最大のビットコインとの相関係数は0.4程度にしかすぎなかったと書かれています。レポート内の相関係数は、生の価格レートではなく変化率から計算したものであることが推察されます。
実は、今回計量分析を行ったのも、前はそうでもなかったのにも関わらず最近元との相関がやたら言われている気がしており、本当にそうなのか?と疑問に思ったからでした。

ちなみに変化率の相関係数は生レートの相関係数よりも有益であることは他の価格指標を基準とした相関係数を計算してみると分かります。
f:id:jpbitcoin:20170111013917p:plain
TOPIXとの相関係数の経時変化を描いたチャートです。年間を通して、USDJPYとの非常に強い相関、S&P500との強い相関が観測されます。逆にGOLDとは弱めの相関があります。生レートの相関係数のように一年のうちに強い相関から強い逆相関に急激に変化する、といったようなことはありません。

本題に戻ってBTCUSDとUSDCNYの相関について、変化率のデータ自体を見て本当に相関がないのか確認してみましょう。

> x.diff$BTCUSD
  [1] -0.0217079278 -0.2217009632  0.2397403084 -0.1352750973 -0.0759203138  0.0590272048  0.0191789425
  [8]  0.1307930610  0.0613321766  0.0064267778 -0.0878949159 -0.0744937854  0.0305853439 -0.1303853572
 [15]  0.0040293707  0.0185152604  0.0439621352  0.0128381051 -0.0378727912  0.0196556411 -0.0615620035
 [22]  0.0236167858  0.0371941606  0.0390911110  0.0386232018  0.0457467746  0.0800878875 -0.0438057372
 [29]  0.0501438768 -0.0427517371 -0.0614557093 -0.0260314596 -0.2060472383  0.0951879356  0.0425685630
 [36] -0.0415982374 -0.0159137877  0.0546857725  0.0051857679  0.0205629608  0.0738773015  0.0789321261
 [43]  0.2278482541  0.0559811599 -0.1363851382 -0.0254515935  0.1535508002  0.0490747714  0.1143886400
 [50] -0.0137887847 -0.0384110100  0.0286135591  0.0337765899 -0.1502190957  0.0124121531 -0.0509749929
 [57] -0.0003960401  0.0737019548  0.0922070629 -0.0033475131 -0.0556317589  0.0050937648 -0.0088758910
 [64]  0.0271732981 -0.0079319130  0.0084852706  0.0142342470  0.0750853932 -0.0396888775  0.0374832513
 [71] -0.0176657587 -0.0215715096  0.1825191031  0.0947747409  0.1865563039  0.0311555590 -0.1004198603
 [78]  0.0346758581 -0.0490126703  0.0371532372 -0.0277862343 -0.0756965750 -0.0279676809 -0.0404606826
 [85]  0.0304380949 -0.0213840424  0.0571549292  0.0004619185  0.0036548214 -0.0028222574  0.0090637540
 [92]  0.0082699535  0.0310905044  0.0178618802  0.0728084565  0.0094906647  0.0033695108  0.0420283080
 [99] -0.0067690100  0.0255839577  0.0355946805  0.0156182666  0.1329975266
> x.diff$USDCNY
  [1] -3.690942e-03  1.495322e-03  4.683918e-03  1.870686e-03 -3.818160e-03 -9.564148e-04  1.566934e-03
  [8]  1.832573e-03 -7.735964e-04 -1.365004e-03 -4.294240e-03 -1.125553e-03 -2.809589e-03  2.275817e-03
 [15] -1.927879e-03 -5.794176e-04 -2.085412e-04 -1.112407e-03 -7.713594e-04  1.354829e-03  8.228527e-04
 [22]  5.038887e-04  7.004266e-04 -2.424876e-03  8.494579e-04 -9.854175e-06 -8.540691e-05 -5.799745e-04
 [29]  0.000000e+00  1.872184e-02  1.612980e-06  2.939416e-02  1.317919e-03 -4.076767e-03 -1.725989e-03
 [36]  3.051730e-04  1.619870e-04 -1.572574e-05 -2.022818e-03 -5.235788e-03  5.848575e-03 -1.084054e-03
 [43] -2.411819e-03  3.494298e-03  3.224726e-03  1.167204e-03  1.601118e-03  1.559486e-03  8.105391e-03
 [50]  4.768318e-03 -5.602539e-04  6.920155e-03  5.550032e-03  2.060793e-03  5.871500e-04  1.271989e-03
 [57] -2.026525e-03 -8.003209e-03  9.169375e-04  4.404283e-03 -5.523735e-03 -2.796431e-03 -2.048502e-03
 [64]  2.417711e-03 -4.167649e-03 -2.331832e-03  2.432220e-03  3.519553e-03 -6.092662e-03  7.538207e-03
 [71]  3.160607e-03  3.291127e-03  4.998510e-03 -2.028679e-03  2.119827e-03 -3.355169e-03  1.253969e-02
 [78]  1.714436e-03  5.454570e-03 -1.614113e-04 -9.136606e-04 -7.545982e-03  4.540421e-03 -3.387949e-03
 [85]  1.916338e-03  3.686953e-03 -7.336642e-05  2.081070e-04  4.714493e-04 -2.716499e-03  3.135307e-04
 [92]  4.098348e-03  6.089475e-03  5.147574e-03  4.577916e-04  1.264483e-03  9.297873e-03  6.923999e-03
 [99]  7.004990e-04  1.237545e-02 -1.148856e-02  7.541433e-03 -1.586967e-03

104週(2年)分のデータについて、同じ方向に値動きした回数を数えてみます(エクセルで)。すると2年間で同じ動きをした回数は52回、違う動きをした回数は50回と全く参考にならない結果になりました(差分をとっているので全データは103個、そのうち一個は変化率ゼロなので除外)。ちなみに最近1年だと同じ動きが33回で違う動きが19回、最近6か月だと同じ動きが18回で違う動きが8回となりました。だんだんと相関が強くなっているような気もしますがそれでも70%程度の一致率ですし、サンプルが少ないとどうしてもばらつきが大きくなるので、データ自体をみただけでも短期的(週単位)な参考指標になるほど相関が強いかと言われれば微妙な感じです。
相関係数の大きさも見ると値動きの大きさにもあまり相関はないと思われます。

ここで一点注意しておきたいのが、一方の要素が他方の要素に遅れて影響を及ぼす場合、相関係数も低く表れてしまうという問題です。週次データなので、1日程度の影響のラグは吸収されるかもしれませんが、もしかしたら週単位で影響の遅れがあるかもしれません。ということでUSDCNYと一週先、二週先、・・・のBTCUSDとの相関係数を見てみます。

> BTCUSD.diff=x.diff$BTCUSD
> BTCUSD.lag=embed(BTCUSD.diff,5)
> BTCUSD.lag=as.data.frame(BTCUSD.lag)
> BTCUSD.lag=transform(BTCUSD.lag,USDCNY.lag=head(x.diff$USDCNY,n=99))
> head(BTCUSD.lag)
            V1          V2          V3          V4          V5    USDCNY.lag
1 -0.075920314 -0.13527510  0.23974031 -0.22170096 -0.02170793 -0.0036909416
2  0.059027205 -0.07592031 -0.13527510  0.23974031 -0.22170096  0.0014953219
3  0.019178942  0.05902720 -0.07592031 -0.13527510  0.23974031  0.0046839180
4  0.130793061  0.01917894  0.05902720 -0.07592031 -0.13527510  0.0018706862
5  0.061332177  0.13079306  0.01917894  0.05902720 -0.07592031 -0.0038181603
6  0.006426778  0.06133218  0.13079306  0.01917894  0.05902720 -0.0009564148

f:id:jpbitcoin:20170111030036p:plain
少し見づらいですが、V5がラグ無しのBTCUSDの変化率、V4が一週先のBTCUSDの変化率、V3が二週先のBTCUSDの・・・となります。図を見れば分かる通りいずれも相関があるとは言えません。
ということで相関分析を行った結果、少なくとも短期的なビットコインと各種指標(ドル元含む)との相関はなさそうであると言えそうです。

ビットコインと人民元との相関を改めて検証

f:id:jpbitcoin:20170111030740p:plain
でも、本当にビットコインと人民元は関係がないのでしょうか。BTCの取引量の大半は中国取引所であることも考慮して価格チャートを見ると、相関がないとはどうしても思えない気がしてきます。(本当は最初に全価格指標との生データの価格チャートを見たほうが良いんですが、スペースの都合上省略。)
ということで時系列データの計量分析を行う時の基本的な流れに沿って改めて検証してみます。なお、記事の長さの都合上、専門用語の説明はかなり省略するのでここから先は訳が分からないかもしれませんが、お許しください。
ちなみにここでは、BTCUSD_{今週}=aBTCUSD_{先週}+bUSDCNY_{先週}+ctとなるような定数abcを見つけることを目標とします。

1.単位根過程か検証

単位根過程というのは、元のデータは非定常過程だが差分をとると定常過程になるデータ系列のことです。定常過程とかって何?と思うでしょうが、ざっくり言えば、定常過程というのは時間依存しないデータ系列であり、非定常過程というのは時間依存するトレンドを含むデータ系列のことです。
定常過程の例を見ると分かりやすいでしょう。例えば、先ほどのBTCUSDの変化率は定常過程だと考えられます。

> plot(BTCUSD.diff,type="l")

f:id:jpbitcoin:20170111032540p:plain
このように、平均が一定(この場合は0)でトレンド成分などが一切ありません。逆に差分をとるということはトレンドを取り除いて相関を考えるという意味があります。経済データを含む時系列データは、多くの場合単位根過程であることが知られており、単位根過程は見せかけの相関が生じてしまうという特徴があります。
単位根過程を調べる方法は、単位根検定と呼ばれますが、ここではBTCUSDに対し二種類の単位根検定を実施してみましょう(計量分析の検定では方法によって結果が異なることがしばしばあります。)。

> pp.test(BTCUSD)

        Phillips-Perron Unit Root Test

data:  BTCUSD
Dickey-Fuller Z(alpha) = -9.3483, Truncation lag parameter = 4, p-value = 0.5742 #p値=0.5742>0.05から単位根過程
alternative hypothesis: stationary

> adf.test(BTCUSD)

        Augmented Dickey-Fuller Test

data:  BTCUSD
Dickey-Fuller = -1.4735, Lag order = 4, p-value = 0.795 #p値=0.795>0.05から単位根過程
alternative hypothesis: stationary

ということで単位根過程であると判断できそうです。
差分をとったデータ系列に対して単位根検定を実施してみると

> pp.test(BTCUSD.diff)

        Phillips-Perron Unit Root Test

data:  BTCUSD.diff
Dickey-Fuller Z(alpha) = -102.35, Truncation lag parameter = 4, p-value = 0.01 #p値=0.01以下より単位根過程でない
alternative hypothesis: stationary

 警告メッセージ: 
 pp.test(BTCUSD.diff):  p-value smaller than printed p-value
> adf.test(BTCUSD.diff)

        Augmented Dickey-Fuller Test

data:  BTCUSD.diff
Dickey-Fuller = -4.5249, Lag order = 4, p-value = 0.01 #p値=0.01以下より単位根過程でない
alternative hypothesis: stationary

 警告メッセージ: 
 adf.test(BTCUSD.diff):  p-value smaller than printed p-value

ということで変化率は単位根過程ではない=定常過程であることがわかります。
USDCNYのデータについても同様であることを確認しました。

2.共和分の関係があるかどうか検証

共和分とはお互いに平衡関係にあるようなことを指します。共和分の関係にあるとは、長期的に見ればお互いに乖離することなく共通の線形(直線的な)トレンドを描くような関係を指します。共和分の関係にあっても相関係数が低いこともありますし、逆に相関係数が高くても共和分の関係にないこともあります。2003年にノーベル経済学賞を受賞した概念でもあります。共和分の関係は単位根過程同士でしか成立し得ないので、まず単位根過程かどうか確認する必要があります(先ほど確認済み)。
いろいろとすっとばして三種類の共和分検定を実施してみましょう。

> BTCUSDvsUSDCNY=data.frame(BTCUSD, USDCNY)
> head(BTCUSDvsUSDCNY)
    BTCUSD  USDCNY
1 272.9486 6.13712
2 267.0873 6.11451
3 213.9783 6.12366
4 271.9491 6.15241
5 237.5409 6.16393
6 220.1743 6.14044
> egcm(BTCUSDvsUSDCNY)
USDCNY[i] =   0.0013 BTCUSD[i] +   5.8882 + R[i], R[i] =   0.9324 R[i-1] + eps[i], eps ~ N(0,  0.0504^2)
             (0.0001)             (0.0361)                (0.0481)

R[104] = -0.1086 (t = -1.055)

WARNING: BTCUSD and USDCNY do not appear to be cointegrated.
> po.test(BTCUSDvsUSDCNY)

        Phillips-Ouliaris Cointegration Test

data:  BTCUSDvsUSDCNY
Phillips-Ouliaris demeaned = -13.185, Truncation lag parameter = 1, p-value = 0.15 #p値=0.15以上により共和分の関係とはいえない

 警告メッセージ: 
 po.test(BTCUSDvsUSDCNY):  p-value greater than printed p-value
> summary(ca.jo(BTCUSDvsUSDCNY,type="eigen",spec="longrun"))

###################### 
# Johansen-Procedure # 
###################### 

Test type: maximal eigenvalue statistic (lambda max) , with linear trend 

Eigenvalues (lambda):
[1] 0.07518300 0.02950148

Values of teststatistic and critical values of test:

         test 10pct  5pct  1pct
r <= 1 | 3.05  6.50  8.18 11.65 #検定量=test=3.05<5%有意水準=8.18より共和分の関係とはいえない
r = 0  | 7.97 12.91 14.90 19.19 #以下すべて同じ

Eigenvectors, normalised to first column:
(These are the cointegration relations)

          BTCUSD.l2 USDCNY.l2
BTCUSD.l2    1.0000    1.0000
USDCNY.l2 -716.8156  329.0447

Weights W:
(This is the loading matrix)

             BTCUSD.l2    USDCNY.l2
BTCUSD.d -7.747367e-02 1.561291e-02
USDCNY.d  9.441207e-05 1.528301e-05

> summary(ca.jo(BTCUSDvsUSDCNY,type="trace",spec="longrun"))

###################### 
# Johansen-Procedure # 
###################### 

Test type: trace statistic , with linear trend 

Eigenvalues (lambda):
[1] 0.07518300 0.02950148

Values of teststatistic and critical values of test:

          test 10pct  5pct  1pct
r <= 1 |  3.05  6.50  8.18 11.65
r = 0  | 11.03 15.66 17.95 23.52

Eigenvectors, normalised to first column:
(These are the cointegration relations)

          BTCUSD.l2 USDCNY.l2
BTCUSD.l2    1.0000    1.0000
USDCNY.l2 -716.8156  329.0447

Weights W:
(This is the loading matrix)

             BTCUSD.l2    USDCNY.l2
BTCUSD.d -7.747367e-02 1.561291e-02
USDCNY.d  9.441207e-05 1.528301e-05

ということで、三種類の検定いずれからもBTCUSDとUSDCNYは共和分の関係にあるとはいえないという結果がでました。

> plot(egcm(BTCUSDvsUSDCNY))

f:id:jpbitcoin:20170111041420p:plain
ちなみに共和分の定義は、「ax_{t}+by_{t}が定常過程となるようなabが存在するとき、x_{t}y_{t}は共和分の関係がある」というものです。上グラフだと真ん中のグラフが定常過程だと共和分ということです。価格の生データよりは定常っぽいですが前半の時期はマイナスが続いていて中盤の時期はプラスで推移して・・・というように微妙にトレンドが出てしまっているので共和分ではないと判定されたのでしょう。

3.VARモデルで推定

次にいよいよBTCUSDとUSDCNYとの関係性をみたり、そこから将来の価格を予測するために、それぞれの価格の関係を考慮した統計モデルを推定します(共和分の関係にあると微妙に方法が変わってきます。)。
まずは価格レートの生データを用います。

> VARselect(BTCUSDvsUSDCNY,lag.max=4,type="trend")
$selection
AIC(n)  HQ(n)  SC(n) FPE(n) 
     1      1      1      1 

$criteria
                 1          2          3          4
AIC(n) -0.01262116 0.02692263 0.04435528 0.07313165
HQ(n)   0.05064040 0.13235855 0.19196558 0.26291632
SC(n)   0.14368905 0.28743965 0.40907911 0.54206229
FPE(n)  0.98749372 1.02745980 1.04583328 1.07692354

> var.raw=VAR(BTCUSDvsUSDCNY,p=1,type="trend")
> summary(var.raw)

VAR Estimation Results:
========================= 
Endogenous variables: BTCUSD, USDCNY 
Deterministic variables: trend 
Sample size: 103 
Log Likelihood: -286.919 
Roots of the characteristic polynomial:
0.9998 0.9236
Call:
VAR(y = BTCUSDvsUSDCNY, p = 1, type = "trend")


Estimation results for equation BTCUSD: 
======================================= 
BTCUSD = BTCUSD.l1 + USDCNY.l1 + trend 

          Estimate Std. Error t value Pr(>|t|)    
BTCUSD.l1  0.92402    0.04442  20.801   <2e-16 ***
USDCNY.l1  0.96255    1.38048   0.697   0.4873    
trend      0.59325    0.25356   2.340   0.0213 *  
---
Signif. codes:  0***0.001**0.01*0.05 ‘.’ 0.1 ‘ ’ 1


Residual standard error: 29.48 on 100 degrees of freedom
Multiple R-Squared: 0.996,      Adjusted R-squared: 0.9958 
F-statistic:  8224 on 3 and 100 DF,  p-value: < 2.2e-16 


Estimation results for equation USDCNY: 
======================================= 
USDCNY = BTCUSD.l1 + USDCNY.l1 + trend 

            Estimate Std. Error t value Pr(>|t|)    
BTCUSD.l1  3.173e-05  4.998e-05   0.635    0.527    
USDCNY.l1  9.994e-01  1.553e-03 643.411   <2e-16 ***
trend     -3.306e-05  2.853e-04  -0.116    0.908    
---
Signif. codes:  0***0.001**0.01*0.05 ‘.’ 0.1 ‘ ’ 1


Residual standard error: 0.03318 on 100 degrees of freedom
Multiple R-Squared:     1,      Adjusted R-squared:     1 
F-statistic: 1.293e+06 on 3 and 100 DF,  p-value: < 2.2e-16 



Covariance matrix of residuals:
          BTCUSD    USDCNY
BTCUSD 869.29252 -0.033521
USDCNY  -0.03352  0.001101

Correlation matrix of residuals:
         BTCUSD   USDCNY
BTCUSD  1.00000 -0.03427
USDCNY -0.03427  1.00000

> plot(var.raw)

f:id:jpbitcoin:20170111050653p:plain
ということでBTCUSD_{今週}=0.92402BTCUSD_{先週}+0.96255USDCNY_{先週}+0.59325tと求められました。
ちなみに一応予測データもプロットすることができます。

> plot(var.raw,n.ahead=26,ci=0.95)

f:id:jpbitcoin:20170111050808p:plain
半年後までやってみましたが、上値が1200ドル弱、下値が800ドル強というところでしょうか。しかし、この手の予測データは特に長期になるほど役に立たなくなっていくので、参考にはしないでください。

4.関係性を推定する

いよいよ最後に本題です。VARモデルから関係性を推定する方法は主に三つありますが、今回はそのうちの二つ、Granger因果とインパルス応答を見てみたいと思います。
まずは、先ほどは参考のため生レートのVARモデルを作りましたが、ここでは差分(変化率)のVARモデルを作ります。

> VARselect(BTCUSDvsUSDCNY.diff,lag.max=4,type="trend")
$selection
AIC(n)  HQ(n)  SC(n) FPE(n) 
     1      1      1      1 

$criteria
                   1             2             3             4
AIC(n) -1.590263e+01 -1.588421e+01 -1.582387e+01 -1.579569e+01
HQ(n)  -1.583899e+01 -1.577815e+01 -1.567539e+01 -1.560479e+01
SC(n)  -1.574535e+01 -1.562207e+01 -1.545688e+01 -1.532385e+01
FPE(n)  1.240490e-07  1.263720e-07  1.342719e-07  1.381831e-07
> var.diff=VAR(BTCUSDvsUSDCNY.diff,p=1,type="trend")
Granger因果

Granger因果とは因果関係を表すものですが、①理論などの仮定に基づかず純粋にデータのみから判断できる②因果の方向のみで関係の強さは分からない、といった特徴があります。Granger因果は単位根過程には適用できません。

> causality(var.diff,cause="x.diff.BTCUSD")
$Granger

        Granger causality H0: x.diff.BTCUSD do not Granger-cause
        x.diff.USDCNY

data:  VAR object var.diff
F-Test = 0.0052849, df1 = 1, df2 = 198, p-value = 0.9421


$Instant

        H0: No instantaneous causality between: x.diff.BTCUSD and
        x.diff.USDCNY

data:  VAR object var.diff
Chi-squared = 0.29621, df = 1, p-value = 0.5863


> causality(var.diff,cause="x.diff.USDCNY")
$Granger

        Granger causality H0: x.diff.USDCNY do not Granger-cause
        x.diff.BTCUSD

data:  VAR object var.diff
F-Test = 3.4514, df1 = 1, df2 = 198, p-value = 0.06468 #(1-0.06468)*100=93.53%


$Instant

        H0: No instantaneous causality between: x.diff.USDCNY and
        x.diff.BTCUSD

data:  VAR object var.diff
Chi-squared = 0.29621, df = 1, p-value = 0.5863

検定を実施するとUSDCNY→BTCUSD方向に93.53%信頼水準(6.47%有意水準)で影響を与えている、という結果がでました。つまり、やはり元のレートが何らかの形でBTCのレートに影響を与えているということは言えそうです。

インパルス応答

インパルス応答はGranger因果とは異なり、関係性の強さも推定できるものです。また、単位根過程(非定常過程)の場合でも使えると言われています。

plot(irf(var.raw,n.ahead=26,ci=0.95))

f:id:jpbitcoin:20170111152551p:plain
f:id:jpbitcoin:20170111152537p:plain
水準レベルでBTCUSDに正の方向に価格ショックを与えてもUSDCNYには全く影響なし、USDCNYに正の方向にショックを与えると影響が出ているように見えますが、5%有意水準の赤点線がマイナスのところまでかかっているので、ほぼ誤差範囲であまり影響なしといえるかもしれません。

plot(irf(var.diff,n.ahead=26,ci=0.95))

f:id:jpbitcoin:20170111153802p:plain
f:id:jpbitcoin:20170111153811p:plain
ちなみに差分に対して見てみても同様にほぼ影響なしとなります(むしろ負の方向と逆に影響)。

まとめ

ということで、計量分析をやってみたら相関があまり見られなかったということになりました。もちろん分析は万能ではありませんし限界もあるので、直ちに関係性が否定されるものではありませんが、言われているほどはっきりした相関ではないのかなという印象です。
このようにあまり相関がみられなかった原因として以下のような仮説が考えられます。

①ドル元レート自体が信用できない

元レートは完全な変動相場制ではなく政府によってかなり管理・制限を受けている相場です。そのため必ずしも人民元価格の下落=中国国内の資産流出の関係にはなっていない可能性があります。

②他の外部要因からの影響が大きい、影響の受け方が複雑

今回は主要な価格指標のみについて考察しましたが、もっと他に大きな影響を与えているものがあったり、あるいは単純に人民元→ビットコインのような流れがあるのではなく、複数の中間通貨・商品等を経て複雑なルートでビットコインへ資産が移動している可能性があります。

③内部要因による影響が大きい

そもそも内部要因による価格への影響が外部要因より大きいという可能性です。ビットコインに関するファンダメンタルズは、供給量であったりトランザクション数であったり他の従来の通貨よりデータが入手しやすいので、内部要因について定量分析してみても面白いかもしれません。

④仕手による影響が大きい

ビットコインはまだまだ市場が小さく仕手による価格操縦の影響が大きい可能性が考えられます。

おまけ

既にお気づきの方もいるかもしれませんが、今回後半で推定したVARモデルというのは最も一般的なモデルではありますが、1期間前のデータのみから現在のデータを説明するモデルであり、同時期に及ぼす影響というのは考慮されていません。そのため、インパルス応答を見てもlag=0のところは当然影響0となります。ということで念のため、SVARという同時点での影響も考慮できるモデルでも試してみましたが同じようにほとんど影響なしという結果が得られました。

> a=diag(2)
> a[1,2]=NA
> svar.raw=SVAR(var.raw,estmethod="direct",Amat=a,hessian=TRUE,method="BFGS")
> plot(irf(svar.raw))

f:id:jpbitcoin:20170111154544p:plain
f:id:jpbitcoin:20170111154559p:plain

> svar.diff=SVAR(var.diff,estmethod="direct",Amat=a,hessian=TRUE,method="BFGS")
> plot(irf(svar.diff))

f:id:jpbitcoin:20170111155015p:plain
f:id:jpbitcoin:20170111161530p:plain

UTXOと残高の話(ビットコインとイーサリアムの台帳管理システムの根本的違い)

久しぶりの更新。時事ネタではなくあまり面白い内容でもないかもしれませんが、書きかけだったので今年中に投稿しておきます。

今回は主に「UTXO」という単語について解説してみたいと思います。ビットコインについて多少勉強したことがある人ならだれでも耳にしたことがある単語だと思います。

ブロックチェーンでの2つの残高管理の方法

ビットコインのような電子通貨の残高を管理するには大きく分けて二つの方法があります。

一つ目は、単純にアカウント(アドレス)の残高を直接データとして記録し管理する方法です。イーサリアムなどで採用されている方法で、特に説明の必要もないほどわかりやすい単純な方法です。

二つ目は、取引データのみをデータとして記録・管理し、残高を取引データから算出する方法です。例えば、アドレスAからBへ10BTC、アドレスBからCへ3BTC移動させるとき、二つの取引から算出してアドレスBには7BTC残っているということが分かります。二つだけの取引なら良いですが、現実的には莫大な量の取引データが存在し、そこから残高を算出しなければならないという非常に面倒な方法で、ビットコインではこの「UTXO」ベースの管理方法が採用されています。

UTXOとは

UTXOとはUnspent Transaction Outputの略で「未使用のトランザクションの出力」と訳せます。UTXOの正体はコインそのものであり、現実世界の現金と同じようなものとして考えられます。現実の財布でも、銀行口座(=残高を直接記録するアカウントベースの管理システム)のように一目で見て残高が分かるわけではなく、一個一個のコインやお札を数えないと合計の残高は分かりません。ただし、UTXOは勝手に盗まれては困るので、現金とは異なりパスワード(=秘密鍵)を知る所有者以外使えないように、所有者(アドレス)情報も付加されています。

ビットコインにおけるトランザクション(=取引データ)は入力(Input)と出力(Output)の二つから構成されています。有効なトランザクションであるためには、①入力にはUTXOとそのUTXOに対応する(秘密鍵から作成される)署名が含まれなければならない②出力部分の合計のコイン量は入力部分より少なくなければならない、という二つの条件が主にあります。①は所有者以外がコインを消費するのを防ぐためであり、②は自分が持っている以上の量のコインを消費できないための当然のルールです。

このトランザクションが送信・承認された後、入力部分に含まれていたUTXOは文字通り使用・消費されているので、もはや「未使用」ではなくUTXOでもなくなります。代わりに出力部分で指定した条件の通り、新しいコイン量と所有アドレス情報が含まれるUTXOが新しく生成します。

UTXOは、現実のお金と同様にカットしたり合体させたりすることはできませんが、トランザクションを介すことで、いわばトランザクション=両替のようなかたちで、細かいお金をまとめたりすることも可能です。

最初のUTXOは採掘者がブロック生成報酬として得たビットコインであり、最初のUTXOが消費され次の新しいUTXOになり、そのUTXOが消費されまた新しいUTXOとなり・・・というように巡り巡って世界中の人々のウォレットの中にUTXO(=コインそのもの)が届くわけです。

UTXOベースのシステムがアカウントベースよりも優れている点

プライバシー・匿名性

UTXOベースのシステムが優れているのが匿名性です。その理由は、UTXOベースのほうがアドレスの再利用が回避しやすくなっているためです。

例えば、アドレスAが所有する5BTCのUTXOを使用してアドレスBに4BTC送信したいときを考えます。このとき、ただ単にアドレスBへの4BTCの送金指示をしただけでは、アドレスAにおつりは戻ってきません。ビットコインでは、入力と出力の金額の差は取引手数料としてマイナー・採掘者に自動的にプレゼントすることになってしまうためです。この場合だと、1BTCも取引手数料として取られてしまうことになります。そのため、4BTCをアドレスBに送るだけではなく、お釣りとして1BTCを自分のアドレスを指定しなければなりません。このアドレスには元の自分のアドレスAを指定しても新しい自分のアドレスCを指定しても大した違いはないので、どうせなら追跡を難しくしようとプライバシーのために新しいアドレスCをお釣り用アドレスとして指定する動機が生まれ得ます。

一方で、イーサリアムのようなアカウントベースのシステムの場合を考えます。アカウント(アドレス)の残高が直接データとして記録されているので、アドレスAにある5ETHのうち4ETHをアドレスBに送りたい、といったとき、単純にアドレスBへの4ETHの送金指示をするだけで済みます。ここから、アドレスの再利用を防ぐために新しい自分のアドレスに送ろうとすると、余分に新たな送金先のデータを追加しなければならず、その分送金手数料も含めてコストが増加してしまい、アドレスの再利用を防ぐインセンティブが削がれてしまうのです。また、特にイーサリアムの場合は、スマートコントラクトの仕様によってはアカウントの再利用を強制させられてしまうこともあります。

ただし、アドレスの再利用さえしなければ、どちらもプライバシーの観点からは変わりません。あくまでアカウントベースは、再利用を避けるような設計になっていないというだけです。

 議論が分かれる点

実装が単純

議論が分かれるという中には入れましたが、実際はアカウントベースのほうが有利とされることが多いのが、実装が単純という点です。

ウォレットの開発を考えてみましょう。アカウントベースの場合、ブロックチェーンに直接残高情報が記録されているので、そのデータを読むだけで残高を知ることができます。また送金を行う際にも、そのアカウントの残高から送金額(+手数料)を引けばいいだけなので、非常に単純に実装することができます。

一方でUTXOベースの場合を考えてみましょう。残高を知るだけでも、UTXOを集めてそこから合計の残高を算出しなければならないという作業が加わります。しかし、特に面倒なのが送金作業を考える際です。送金作業ではどのUTXOを支払いに使用するかを決めなければなりません。取引手数料やデータサイズ削減のためこのUTXOの選択作業がかなり複雑になるのです。

これは現金でのやりとりとまさに同じです。123円のような買い物で小銭で支払えるのにも関わらず、小銭をいちいち出すのが面倒だからといって、毎回千円札を出していると小銭が溢れて財布の中身が訳の分からないことになるのによく似ています。溢れた分は貯金箱・・・という人もいるかもしれませんが、ビットコインではそういう訳にはいかないので、最終的には細かくなった小銭からなんとか探し出して払うしかありません。

特にビットコインの場合、取引手数料が取引データのサイズから決定されるという特徴があります。つまり、「小銭」ばかりをまとめて使っていると手数料が大きくなってしまうというデメリットもあるのです。そのため、毎回なるべく少ない数のUTXOからなるべくお釣りが小さくならないようにUTXOを選ばなくてはなりません。さらにいえば、取引承認の優先順位は、「Coin Age」というどれだけUTXOの未使用期間が長いかという指標も考慮されるので、できるだけ古いUTXOを選んだほうが良く、coin ageの概念は使用されなくなりました。)また、プライバシーを考えたければ異なるアドレスのUTXOはなるべく使わないようにしなければなりません。

これらの事情をすべて考慮すると多くの条件分岐のコードを書かなければならなくなってしまいます。

現実問題として、ビットコインでは実装が面倒だったり取引手数料の仕組みが初心者にはわかりづらかったりする程度で、UTXOによる複雑さはそこまで大きな問題にはなっていないのですが、イーサリアムのように通貨情報だけではなくスマートコントラクトのために他の情報を付加する必要があるような複雑なシステムの場合は、複雑さが大きなデメリットとなり得ます。実際に、イーサリアムだけでなく、NxtやNEMのような通貨機能だけにはとどまらないプラットフォームの多くが同様のアカウントベースのシステムを採用しています。

しかし、アカウントベースのシステムが単純で万々歳かというとそういう訳でもありません。例えばアカウントベースの場合、Replay Attackという攻撃に対する耐性が低いと考えられています。Replay Attack自体の話からはじめないといけないので詳しくは省略しますが、これは、ビットコインがトランザクションベースであり、UTXOを消費するたびに新しいUTXOが生成されるので、アドレス内の残高の内訳(=UTXO)を区別するのが容易ということに主に起因しています(例えば、ビットコインがETCのようにフォークしたとき、同じアドレス内のオリジナルビットコインとフォークビットコインを一度分離すれば、その後は同じアドレス内に移動させてもUTXOが異なる場合、そもそもReplayできません。)一方で、イーサリアムのようなアカウントベースでは、基本的に残高ベースで管理されているので、その残高がどのトランザクションからきたものかということは気にされず、同じアドレスに二つ以上のフォークしたブロックチェーンのコイン残高がある場合、見分けるのが非常に難しくなり、簡単にReplayできてしまいます。

イーサリアムにもトランザクションにnonce(=ワンタイム識別子)をつけることで簡単に二重支払いができない仕組みがあり完全に無防備というわけではありませんでしたが、実際にイーサリアムクラシックが生まれた際にはReplay Attackが広く発生してしまいました。この対策には、UTXOよりもアカウントベースのほうが複雑な仕組みを要します。

スケーラビリティが優れている

理論的には通信速度・帯域的な意味でUTXOベースのほうがアカウントベースのほうが優れているとされています。これは、同じアドレスからの送金を考えた際に、同じ金額であっても複数のUTXOを別々に並行処理できるためです。アカウントベースの場合は、逐次的に一個一個処理するしかありません。しかし、現実的には入力部分のUTXOが複数になるとサイズも増加し手数料が増え、また、実際に都合よく複数のUTXOを使えるような場面が多いわけではなく、UTXOをウォレット内に無駄に増やそうとすると前述のように複雑になってしまう問題もあるので、現実的なメリットはほとんどないと考えられます。

HDD容量的な意味で優れているとされるのがアカウントベースのほうです。単純に全アドレスよりも全UTXOの数のほうが多いので、UTXOのデータをすべて保存するよりもアカウントの残高を直接記録・保存するだけのほうがサイズが小さくなるイメージは分かると思います。実際にビットコインのスケーラビリティ問題の一つとして、UTXO全体のサイズ増加も大きな問題として挙げられています。

とはいえ、アカウントベースはスケーラビリティの点から見て優れていると断言できるほど単純ではありません。単なるウォレットならまだしも、ノードやネットワーク全体を考えた時、実際問題、残高情報だけを記録しているだけでは二重支払いや前述のReplay Attackを防ぐのは難しく、取引データに関連する情報も保存・一部参照しなければならないため、むしろUTXOだけで良いのに残高情報など余計なデータを管理している分UTXOベースのほうが優れているとも考えられます。

まとめ

結論的にはどちらのシステムも一長一短があり、どちらが良いとは一概に言えないものです。

普通のユーザーはUTXOなんて知る必要はありませんが、知っていればビットコインの取引手数料決定の仕組みなどについてちょっと理解がしやすくなるかもしれません。

仮想通貨関連の情報源まとめ(ビットコインデータ編)

かなり前にまとめリンク集のような記事を書きましたが、続きを書いていないことを思い出したので今回はビットコインのデータ関連で有益と思われるサイトについてまとめたいと思います。

意外とこういうリンク集を乗っけているところがあまりないので、いずれサイトにコンテンツとして掲載するかもしれません。有名なサイトばかりで知っている人も多いと思いますが、とりあえずは備忘録としてこのブログにまとめておきます。

Bitcoin Fees for Transactions | bitcoinfees.21.co

https://bitcoinfees.21.co/

ビットコインの手数料の目安を表示してくれるサイトです。このまとめのなかでも実用上唯一見る機会があると言ってもいい便利なサイトです。

最近は送金がなかなか確認されないトラブルが頻発してるようなので、このサイトを見て手数料を決めればスムーズに送金することが可能です。緑のグラフ帯の手数料だと遅延なしで送れるようです。ただし、ビットコインの仕様にあわせて1バイト当たりの目安手数料しかかかれていないので、トランザクションのサイズをいちいち確認する必要があり、サイズが確認不可能なウォレットでは利用が難しいです。グラフの下のほうに、太字で平均(中央値?)のサイズとそれに合わせた目安の手数料がかかれているので、サイズが不明な場合はその目安の手数料を設定すると良いかもしれません。

いずれにしても、トラブルで困りやすい初心者に進めるにはちょっとハードルの高いサイトなので、手数料・送金遅延問題についてはもっと多くのウォレットが手数料を自動調整してくれる機能を実装してくれることを願っています。

Bitnodes

https://bitnodes.21.co/

ビットコインのノードの分布を掲載しているサイト。普段あまり使うことはないと思いますが、バージョン別の適用状況なども見れるので便利です。サイト内ではIPを入れるとビットコインのノードがちゃんとたっているか確認できるツールもあるので、個人的には自分で新しくノードを立ち上げるときなどに使っていました。

Coin Dance

https://coin.dance/nodes

ノード関連でサイトをもう一つ。ここでは、Bitcoin Core以外のClassicやUnlimitedなどのノードの推移を見れるのが便利です。

Bitcoin network graphs

http://bitcoin.sipa.be/

ビットコインのコア開発者のsipaことPieter Wuilleが運営するサイト。ハッシュレートや現在も行われているソフトフォークの投票状況(block version)の推移などのグラフが確認できます。

信頼性は他のサイトより高いと思われるので、ハッシュレートなどのデータを確認したいときはとりあえずここのグラフを見ています。

Blockchain.info

https://blockchain.info/ja/charts

有名なウォレット兼ブロックエクスプローラーのサイト。ブロックチェーン関連のデータも掲載されています。細かく一つ一つ見ていくとデータの根拠・信頼性がよくわからないものもありますが、マイニングプールのハッシュレート分布なんかは参考になるので時々見ています。

data.bitcoinity.org

http://data.bitcoinity.org/

価格チャートサイトですが、世界の取引所の取引量などのデータも掲載されています。Coindeskのレポートなんかでもここのデータが引用されているので、一番有名なデータではないかと思います。ただし、日本の取引所を含めある程度の規模の取引所であっても掲載されていなかったりしていて、主要取引所のみという感じなので、通貨別の取引量を見るときなど注意が必要です。

Coinhills

https://www.coinhills.com/

同じく取引量関係でもう一サイト。見せ方としてはこちらのほうが面白いです。ただし、ここも全取引所が掲載されているわけではなく網羅的ではないので、この手のサイトの取引量を見るときは一応念頭に置いておきましょう。

p2sh.info

http://p2sh.info

P2SH関連のトランザクションデータをまとめたサイト。P2SHの説明は省きますが、マルチシグネチャアドレスの使用状況や、RBF(Replace-by-Fee)の使用状況などのなかなか面白いデータが見れます。Segwitが採用された際には、Segwitアドレスの使用状況もこのサイトで見れるようになるのではないかと思います。