Electrumサーバーを建ててみた

以前作成したビットコインのフルノード機にElectrumサーバーをインストールしてみたので、万人向けではありませんが、その記事を書きたいと思います。

Electrumサーバーについて

Electrumはビットコインの代表的なデスクトップウォレットの一つで、現在はAndroid版なども公開されています。サーバー・クライアント型のウォレットで、クライアント側はbitcoinノードも兼ねるElectrumのサーバーに接続して残高情報を取得したり、送金作業を行ったりすることになります。

以前は公式のサーバーソフトしかなく、そのソフトの必要リソースが非常に大きかったのでサーバーを建てるのが難しかったのですが、最近になってElectrumXという軽量版のソフトが公開されたので、今では動かすためのハードルがかなり低くなりました。ということで、せっかく寄付をもらって立ち上げたフルノードなので、ウォレットのサーバーとしても稼働させることにしました。

今回は公開のサーバーにしていますが、プライベート設定にして自分専用にすることもできますし、サーバーを建てることでフルノードと同様のプライバシーを兼ね備えつつElectrumを利用することができます（万が一のハードフォーク時には、自分でフルノードを運用することで他人のノードを信用しなくてもよくなるので、セキュリティにも寄与します。）。

必要リソース

ElectrumXの具体的な動作環境は記載されていませんが、bitcoindの設定を絞ってメモリ1MBのRaspberry Pi 3で動かしている人もいるので、かなり貧弱なコンピュータでも動かすことができるようです。ちなみに、bitcoindとElectrumXを別々のコンピュータ上で動かすことも可能です。

ただし、低スペックのコンピュータの場合、データベースの保存にHDDではなくSSDを利用することが重要です。今回も、最初はHDDで動かしていたのですがあまりに遅くて試しにSSDに換えたところ処理速度が10倍以上に向上しました。ElectrumXのデータベースをSSDに置くだけで、接続はUSB2.0だろうが全然パフォーマンスが違うので、最新のPCでもない限り、VPSで運用する場合もRaspberry Piなどで運用する場合もとにかくSSDということをおすすめしたいです。

インストール手順

Linuxの操作に全く慣れていなかったり経験がないような人にはわざわざサーバーを建てることはおすすめしないので、さらっと簡潔に書いてしまいます。

インストール手順はgithubのページを見てもらうのが一番良いかと思います。必要環境はpython3.5.3以上（3.6をおすすめ）に加え、Pythonのライブラリとしてaiohttp、pylru、plyvel(LevelDB)またはpython-rocksdb(RocksDB)が最低限です。

Raspberry Piの場合はコマンドを列記したスクリプトも用意されているので、参考にしてみてください。

注意点

Electrumは基本的にSSLを利用して通信するので、サーバー側もSSL証明書を用意することになります。自己署名証明書でも問題ありませんが、サーバー設置後なんらかの原因で紛失した場合は、同一の証明書でない限りクライアント側から無効と判断されるので、バックアップをとっておくことが重要になります。Electrumでは、クライアント側は各サーバーのアドレスに対応する最初に取得した証明書をもとに、その証明書が有効かどうか判断するようになっているので、前の証明書が用意できなかった場合、サーバーのドメイン名を変更しなければなりません。

起動

セットアップが終わったらサーバーを起動することになります。最初はElectrumXのデータベースを最新のブロックまで同期することになります。コンピュータのスペックにもよりますが、bitcoindの同期と同じぐらいかかるようです。最初の同期を省略するために、定期的にデータベースをウェブ上にアップロードしてくれている人もいるので、必要な方は拝借すると楽でしょう。

実際に運用中

ということで実は一か月前くらいからElectrumサーバーを運用し続けています。ElectrumXのアップデートに対応するため定期的にソフトの再起動をかけているので時々急落していますが、平均すると常時300クライアントぐらいの接続があるようです。

現在のサーバー数は大体100前後を推移していますが、同じサーバーでもTor用サーバー(.onionで終わるアドレス)が別にカウントされたり、一部ネットワーク上に表示されないサーバーもあるので、下のグラフは必ずしも正確なデータではありません。

サーバーによってセッション数（接続クライアント数）はかなり変わってくるのではっきりとは言えませんが、単純計算だと300*100=30000人程が常時Electrumを起動していることになります。ただし、Electrumはサーバー・クライアント型であると同時にSPV的な認証もしており、1サーバーに対してアドレスの残高情報を問い合わせたりトランザクションデータを通信したりするだけでなく、1クライアントにつき7,8台のサーバーに同時接続して各サーバーのデータ間に相違がないか検証するので、実際は30000の1/7か1/8程で約4000人前後という感じ、多く見積もったとしても1万人はいかない程度になると予想されます。

このノード機は液晶画面もつけているのでElectrumX用のデータも表示するようにしました。※画面のディスク占有量はElectrumXのデータベースを保管するSSDのみを表示。現在は20GBくらいです。

まとめ

Electrumのサーバー数はElectrumXの公開後大幅に増加したので、ネットワークの貢献という点では現在はあまり意味がなくなっています。ただし、低スペックのコンピュータでも運用できるようになったという点は非常に大きいので、フルクライアントのウォレットを利用したいという方にとっては大きな選択肢の一つとなりました。

同じように自分のフルノードに軽量型ウォレットから接続したいという場合、Android用のBitcoin Wallet(schildbach)を除くとBitcore&Copayの利用が最も有名で情報も多い上にCopayのマルチプラットフォーム対応のおかげで汎用性が高いのですが、単純な手軽さでいうとElectrumに軍配が上がる気がします。Android用のElectrumはサーバーのIP直打ちができませんしiOS版はリリースすらされていないので、まだまだ不便ですが興味のある人は試してみてはいかがでしょうか。

Segwit有効化に向けて前進する？ASICBOOSTとその対策提案について

次の記事は久しぶりにアルトコイン系のものを書こうと思っていたのですが、なかなか調べるのが進まないので、引き続きビットコインの話題です。

内容は数日前から話題になっているASICBOOSTについて。Bitcoin Unlimitedとかスケーラビリティの話はExtension Blocksとか新しいワードが毎日のように出てきていて正直ついていけなくなっていたので、ほとんど調べずにスルーしていましたが、今回の話はSegwitの採用プロセスが始まってから初めてのCore側からの具体的なアクションになるので、調べてみることにしました。

ASICBOOSTについては既に以下のような記事が書かれており、概要を掴むには同記事を読むだけで十分です。何も知らない人は以下の記事を参照すると良いかと思います。実際はもう少し複雑で勘違いするひとも多そうな話なので、ここでは詳細に内容を説明してみます。

ASICBoost＝中国マイナーがSegWitに反対する理由が判明する | ビットコインの最新情報 BTCN｜ビットコインニュース

ASIC BOOSTの手法と対策について | ビットコイン研究所

ASICBOOSTとは

技術的なことはなるべく省略して説明したいと思います。簡単に言えば、ハッシュ計算（SHA-256）の対象であるブロック内のデータをちょっといじくることにより、消費電力を20～30%を節約することを「ASICBOOST」と呼びます。マイニング工場のハッシュレートのボトルネックが電力である場合（おそらくほとんどの場合そうなっている？）、ハッシュレートも上昇することになります。

covert ASICBOOSTとovert ASICBOOST

今回特に問題とされているのが、ASICBOOSTの中でも「covert ASICBOOST」と呼ばれているものです。covertというのは、hiddenとかsecretに似た意味であり、要するに非公開のASICBOOSTのことを指します。covertなので、ASICBOOSTを実際にやっているかどうかは、採掘されたブロックの情報を分析しても分かりません（ブロックの情報がcovert ASICBOOSTの証拠にできるという情報が一部に流れていますが、可能性があるということがわかるだけで、ASICBOOST搭載のマイニングチップに不備でもない限り断言できる確実な証拠が見つかることはありませんし、はっきり分かった時点で「covert」とは言えません。）。

overtというのはcovertの対義語で公開のASICBOOST、つまり誰にでもASICBOOSTを行っていると分かるかたちのものです。現在のところ採掘に際しovert ASICBOOSTを行っているマイニングプールはありません。

技術的にはcovert ASICBOOSTはブロックの中のMerkle rootという部分をいじくることで効率を上げ、overt ASICBOOSTはversion bitsという部分をいじくることで効率を上げるという違いがありますが、どちらも20～30%の効率化というパフォーマンス面での大きな違いはありません。

covert ASICBOOSTの問題点

最大の問題点はcovert型はSegwitをはじめとするビットコインプロトコルの「改善」に互換性がない、ということです。詳細は説明しませんが、現在採用プロセス中のSegwitだけではなく、(U)TXO Commitment、Committed Bloom filters、Fraud Proofsなどの今後実装が期待される技術にも互換性がないとされており、covert ASICBOOSTを許してしまうとこれらの新技術がすべて実装できないことになってしまいます。

特許の問題

一連の話のなかで重要なキーとなっており、かつ上記の互換性がない問題と並んで大きい問題となっているのが特許です。正直特許の話については、各国の特許や法律の関係については詳しくありませんし、具体的な内容が不明なこともあり、軽く調べただけではよくわかりませんでしたが、わかる限り説明してみたいと思います。

ASICBOOSTはそもそも2014年にTimo HankeとSergio Demian Lernerという人が考案したものであり、二人がアメリカでの特許を持っているとされています（現在はSergioは放棄してTimo一人が持っているという話もあり）。

ただし、その後二人の考案者が関わっているのか完全に別々な動きなのかはよくわかりませんが、2015年に中国のASIC製造業者であり75%ともいわれるシェアを持っているBitmainも同じようなASICBOOSTの特許を中国で取得しているとされています。

特許を持っているというのは、つまりその技術を独占できるということを意味します。BItmain自体は今回の騒動の中で、ASICBOOSTの機能がマイニングチップに含まれていることを認めながら、testnetでテストしたことはあるがmainnetで使用したことはないと主張しています。この主張が本当であれば大きなインパクトはないのですが、嘘であった場合は今までSegwitに反対してきた本当の理由はcovert ASICBOOSTが使えなくなるからではないか、ということが推測されるわけです。

ASICBOOSTについては全員が使っていれば違いが生まれないので大きな問題はないのですが、ビットコインに対する特許の悪影響として、特許の制限により一部しか使えないためにマイニングプールの集中化がより進むことが考えられます。

また特許の保有者（Timo及びBitmain）から訴えられる恐れが少ないという点で、マイニングプールが基本的には同じ性能であるovert型ではなく証拠が出てこないcovert型を秘密裏に使用するインセンティブにもなり得ています。

特許の問題は、特許がフリーライセンスであれば解決される可能性が高いと考えられますが、現在のところTimoのアメリカの特許もBitmainの中国の特許も有料になっているようです。

 実際に法律的にどうかとか細かい話は、専門家ではありませんし、Timoの特許は保留中であるとか、Bitmainの特許は実は無効なんじゃないかとかいろいろな話が出てきていることもあって複雑なのでよく分かりません。

 ASICBOOSTに対する対策の提案

ということで、前述のASICBOOST対策の提案が数日前にCore開発者の代表格であるgmaxwellより出されました。

 ASICBOOSTは「攻撃」なのかそれとも「最適化」であるかという議論がありますが、gmaxwellは提案の中ですべてが攻撃であると記述しながらも、特に緊急で重要度の高いビットコインプロトコルの改善の障害となるcovert ASICBOOSTのみをブロック、無効にする提案を出しています。過去にもASICBOOSTの対策の議論がありましたが、現状では他のovert型については特許の問題は残されているもののコミュニティの議論に委ねるとしています。

overt型は特許の関係でマイニングの集中化がすすむリスクや、version bitsを利用するためBIP9によるソフトフォークプロセスに軽微な影響がでるリスク（同時にできるソフトフォーク実行数が29個から十数個に減る程度）が考えられますが、現在のところ実際には行われていませんし、covert型とは異なりSegwitのような新技術との互換性があり、特許が完全にフリーライセンスになれば実質的に無意味なものと化すので、重要度は低いということです。

ASICBOOSTすべてが攻撃であるとか逆に最適化であると考える人もいるでしょうが、プロトコルの改善を阻害するcovert型のみが攻撃で対策すべきと考える人や特許による独占が問題だと考える人もいると考えられますし、白か黒かの単純な話でもないのでここらへんの議論には注意が必要です。

なお、この提案はSegwitでも利用されている95%のマイナーの賛成を必要とするBIP9ソフトフォークではなく、最近話題になっており前回も記事に書いたいわゆるUASFのようなかたちで、特定のブロック高でマイナーのハッシュレートに関係なくソフトフォークを実行する予定のものとなっています。

提案は出されたばかりであり、具体的な日付は決まってませんし詳細が変更される可能性もありますが、他の中心的なCore開発者たちは概ね賛成のようですし、BIP9のより安全なソフトフォークではないため「コミュニティのサポート」が必要としながらも、支持しない場合は新バージョンのCoreを利用しなければ良いという論理で、次々バージョンの0.14.2以降に組み込まれる可能性が高いと考えられます。

なお、covert ASICBOOSTはSegwitと互換性がなく、Segwitが有効化されることでも自動的に対策されることになるので、その場合は提案のソフトフォークの必要はなくなることになります。

Segwit有効化のためのシナリオ

また一ヶ月後には全く状況が変わっていてこの内容も的外れになっているかもしれませんが、この提案により今まで考えていた状況と大きく変わってきたので、Segwit有効化のために考えられるシナリオを最後に書いておきます。もちろんSegwitが永久に有効化されなかったり、Coreチームが解散してBitmain coinになってしまったりする最悪の可能性もあります。

①11月までに現在のBIP9下で賛成ハッシュレートが95%に達し有効化

最も理想的ですが最も楽観的で可能性も低そうなシナリオです。ASICBOOSTを反対派のマイナーが利用していて実はSegwit反対の真の動機であったという仮説が誤っていれば絶望的ですが、正しければマイニングプールが降参して賛成に転じたり、先の提案が11月までに実行されれば反対の動機がなくなって95%に達する可能性もないわけではないと考えられます。

②UASF(BIP148)によりSegwitが有効化

前回の記事でUASFについて書いた時は詳細が明らかになっていませんでしたが、その後BIP148というかたちで明確化し、BIP148適用のノードを運用できるパッチまでリリースされるようになりました。Core側に実装される予定のものではなくshaolinfryという例の人が書いたコードですが、BIP148の仕様の決定後はいくつかのCore開発者の中には意見を言う人も出ており、luke-jrやpetertoddなどは割と前向きな雰囲気を出しています。

ただし、ASICBOOSTへの対策の提案も行ったgmaxwellはBIP148に対して単純なUASFからやや離れた仕様やそもそも性急すぎる（今年の8月より開始）ことに否定的なコメントを出していますし、Coreノードに直接BIP148が実装される雰囲気は全くありません。

UASFの有効化は単純なノード数ではなくいわゆる「economic majority」と呼ばれる世界の取引所や決済サービス企業などの適用が最重要となるので、先日のハードフォークに対する声明でも見られたように特に中立性を強調することが多い取引所を考えると、Coreにもマージされていないパッチが圧倒的支持を得る可能性はかなり低いと思っています。

③11月のSegwit期限以降に再度ソフトフォークプロセスを実行、有効化

一連の騒動を受けて改めて考えると、この可能性が最も高くかつ比較的安全であると思うようになってきました。Segwit採用期限の11月15日までに有効化されなければもうSegwitは終わりだと思われている節がある気がしますが、今回の採用プロセスが終わりというだけで、CoreチームがコミュニティのSegwitに対する賛成状況を見てBIP9のプロセスをやり直すことなどは理論的には十分あり得るのではないでしょうか。

最も安全・確実な方法だった95%の賛成率を要するBIP9ソフトフォークは失敗したが、それはマイナーの攻撃によるためで、ノード数の状況などからコミュニティのSegwitに対するサポートは十分あるため、条件を緩くして再度実行という論理で、BIP9ソフトフォークで閾値を下げるかUASFソフトフォークのコードをBIP148とは別に書いてCoreに実装という流れが実際には考えられます。

④Segwit反対派がハードフォーク、Core側でSegwit有効化

ハードフォークシナリオ。最近はもうないだろうという風潮になっていますが、可能性としてはゼロになった訳ではないと思います。前回の記事ではいっそハードフォークと書いては見たものの、やはりあらゆる面で大変なので止めてほしいです。ただし、Core開発チーム的には攻撃されてもいくらでも対処法はあるというような余裕な雰囲気を醸し出している気がするので、怖いもの見たさに見てみたいドラマというのは言えます。

Bitcoin UnlimitedとCoreの対立について

ビットコインのETFが非承認になって、とりあえずしばらくの間はスケーラビリティ問題に話題が移りそうです。ということで、Bitcoin UnlmitedとCoreの対立についての簡単なまとめと私見を書いておきます。

Bitcoin Unlimited

Bitcoin Unlimitedとは、ビットコインのブロックサイズ上限1MBを撤廃して、ダイナミック（可変的）にブロックサイズを決定しようとするソフトウェアのバージョンです。「公式」のソフトウェアはBitcoin Coreと呼ばれており、その開発チームとは別の人々によって立ち上げられました。

現在のビットコインのブロックは、もうだいぶ前から1MB上限に達しており、最近は特に混雑具合が増して必要手数料が増大する状況になっているので、すぐにでもブロックサイズを上げなければならないという観点等から主にBitcoin Unlimitedの支持者が増えています。

現在はSegwitをソフトフォークによって実装するプロセスが実行中ですが、Bitcoin UnlimitedはSegwitに否定的であるというのが特徴です。その理由は、ソフトフォークはハードフォークよりも複雑だとか、Segwitやその後のLightening Networkによりマイナーの手数料が減るとか、SegwitはBlockstream社（サイドチェーンなどを開発するCore開発者の何人かが所属するブロックチェーンの開発企業）の商品でSegwitが実装されればBitcoinはよりBlockstream Coinになってしまうとか様々なことが言われています。

正直なところ個人的にはSegwitの否定的な意見に納得できるところはほとんどなく、政治的な道具になってしまっているという印象です。

また、Bitcoin Unlimitedは技術的にも以下のような危険性が指摘されています。

Bitcoin Unlimitedの設計哲学「突発的コンセンサス」が危険な理由 | ビットコインの最新情報 BTCN｜ビットコインニュース

この件を含め、開発チームの開発力にも疑問があり、公開の定例ミーティングなども一切やっておらず、Coreの開発チームと比べると相当レベルが下がるのではないかという印象です。

そんなわけで、ダイナミックなブロックサイズ変更という根本思想一点には賛同できますし、Coreは現状を見ていますぐブロックサイズを上げるべきと感じます。ただし、Bitcoin Unlimitedにはその他で納得できるところがほとんどないので、Coreのほうが好ましいと思っています（日本には「Unlimited派」の人がほとんどいない気がするので、意見を発信してくれると面白い。）。

Segwitも持ち上げられすぎ？

同時に感じているのがSegwitが持ち上げられすぎではないかということです。「Core派」の中には、Segwitによりブロックサイズ上限が実質的に約2MBまで上昇するので、ハードフォークによってサイズ上限を引き上げるのと同じ効果だから、とりあえず賛成に回れという人もいますが、実質的に約2MBというと（当ブログ記事でも過去に書いてしまいましたが）語弊がある表現になってしまうかもしれません。

というのもSegwitを利用するには新しいアドレス形式（マルチシグネチャと同じ3からはじまるアドレス）を利用しなくてはならないからです。Segwit実装後も、もしすべての取引が現在の1からはじまる普通のアドレスや3からはじまるマルチシグネチャアドレスのみから行われれば、ブロックサイズ上限は1MBのままです。

一般のユーザーがSegwitの新しいアドレス形式を理解して、広く使われるようになるにはかなり長い時間がかかるものと思われます。このため、Segwitが実装されたらすぐに手数料が元に戻って安くなるというのは楽観的すぎる見方かと思います。

また、Segwitはトランザクション展性を根本的に修正するのが主目的ともいえるものですが、同様に新しいSegwitアドレスを利用しなければ全く意味がありません。今までの1からはじまるアドレスには引き続きトランザクション展性が存在し、何回かソフトフォークによって修正対応はされており「Segwit待ち」のソフトフォークによる修正計画（BIP146）も現在あるのですが、今後も新たな脆弱性が見つかった場合には都度修正する必要があります。

UASF

さらに最近もう一つ話題になっている「UASF」というものがあります。これは、User-Activated Soft Forkの略です。そのまま訳すと「ユーザー主導のソフトフォーク」的な意味になり、語感から言うとノードの賛成比率からソフトフォークを実行するの？と勘違いされがちですが、全く違います。

別の言い方として「Flag-day soft fork」と言われることがあり、こちらのほうがより正確です。要するに、特定の日になったらマイナーのハッシュレートにもノードのアップグレード率にも関係なく強制的にソフトフォークをしようとするものです。マイナーのSegwit賛成率がなかなか上がらないので、ユーザーが賛成すればSegwitを実装できるようにしてしまおうという考えが背景にあります。

このUASFは、なぜかCore派の代表的主張として取り上げられることが多いのですが、最初の発端は「shaolinfry」という匿名の人物がビットコイン開発チームのメーリングリスト及びbitcointalkに投稿したことであり、Coreの開発チームから話が出たわけでは全くありません。

実際的にUASFについては、Coreの開発チームはほとんど無反応という感じです。「Core開発者」の範囲をどこまで広げるかにもよるのですが、広い範囲でいうと正直誰がそうなのかほとんど把握していないので、IRCの定例ミーティングに毎回出席しているような「コアな」Core開発者に限って言うと、Luke-jrが低いマイナーのハッシュレート下では実質的にハードフォークとなる危険性を指摘し、75%程度のハッシュレートを必要条件としたほうが良いという提案（＝つまり今のBIP9ソフトフォークの閾値を下げるだけ？）をメーリングリストやredditでしています。その他、gmaxwellが「興味深い提案だけど、何か意見を言うのは時期尚早。いろんな意見が出るのはいいこと。」とredditで発言するにとどまっています。

その他、「Core派」の普通のユーザーの中にもUASFによるフォークの危険性を指摘する人が多くいて、本当に本気でUASFを実行したいと考えている人が多いのかは疑問です。

また、実はUASFの考えは新しいものではなく、Nakamoto Satoshiが開発していた時代のソフトフォークは、まさに特定の日が来たら強制ソフトフォークを実行するというUASFとほぼ同じ考え（UASFはBIP9のソフトフォークプロセスを前提としているので厳密に言えば違います）のものでした。

その後、安全性・安定性の観点からBIP16でハッシュレート55%を閾値とし、BIP34でFlag dayを撤廃したうえでハッシュレート75%を閾値とし、さらにBIP65,BIP66では95%を閾値として、現在のBIP9の複数段階のソフトフォークプロセスに移行してきたという経緯があります。正直なところ、過去の仕様に戻すようなUASFがなぜこんなに話題になっているのか謎ですし、Coreの開発者たちの思想からいって実際に行われる可能性は限りなく低いのではないかと思います。

あったとしても、急進的な別グループがUnlimitedと同じような感じでフォーク版を作るということにしかならない気がします。

最も良い今後のシナリオは？

Bitcoin UnlimitedがCore側と和解してSegwitも採用というのが万々歳な未来ですが、今の状況を見ているとなかなか一筋縄ではいかなさそうです。よくCore側とUnlimited側が決裂してハードフォークというのが最悪なシナリオと言われますし最近まで自分もそう思っていましたが、むしろ膠着状態のまま何もできないのが最悪なのでは？という気がしています。

もしUnlimited側がハードフォークすれば、（中立の立場のマイニングプールがいないという条件のもとでは）Core側のチェーンにSegwit反対派がいなくなるため95%を自動的に達成し、CoreチェーンにSegwitが実装されることになります。同じ理屈で、Unlimited側でハードフォークを意図的に行わなくても、低いSegwit賛成率では危険なので難しいですが、もし90%程度まで達するのであれば、Unlimitedブロックを無効なものとCore側のマイナーが判定することで、強制的に95%へもっていくことも可能です。

実際にハードフォークが行われれば、ハッシュレートの低い方のチェーンは消え去るというある意味楽観論もありますが、やはりETHとETCの例を見ていても二つとも少なくとも短期的には生き残るのではないかと思います。ハードフォークにより価格は恐らく大暴落するでしょうし、ETHとBTCはさすがに規模が違うので取引所の対応やユーザーの対応はとんでもなく大変になるでしょうが、このまま何年も膠着状態を続けるくらいなら、いっそ長期的に見れば早く（Unlimited側が）ハードフォークしてくれたほうが良いのでは？というお話しでした。

参考サイト

[bitcoin-dev] Moving towards user activated soft fork activation

Version bits extension with user defined activation · GitHub

Segwitを採用する(予定の)アルトコインを調べてみた

少し前にLitecoinのSegwit採用が話題になり、最近はMonacoinが話題となっているので、他のアルトコインはどうなのか調べてみました。

ACTIVE（採用済）

Groestlcoin

ほとんど話題に上がっていませんが、世界初のSegwit採用コイン。PoW型でGroestlというGPU/CPUマイニングのみのハッシュアルゴリズムとなっています。アルトコイン乱立全盛期の終わり頃？の2014年3月にスタートしており、Groestlという他では採用されていない関数を使ったという一点でそこそこ目立っていたほうではあるので、知っている人は知っているかもしれません。

採用プロセスはビットコインと同じ2016ブロックごと、95%がしきい値の設定ですが、ブロックタイムが1分なので、ビットコインの2週間に対してわずか1日余りが1投票期間になります。

ブロック番号#1435392（1月21日）からシグナル（投票）が開始され#1437408（1月23日）には95%を超え採用が決定されました。最初の期間で95%を超えたことになります。単一のマイニングプールが支配しているとかではないようですが、現在は時価総額180位の超マイナーコインなので、小規模だからこそ迅速にできたと言えるのかもしれません。

STARTED（投票期間中）

厳密に言うと「投票」は語弊があり怒られそうな気がしますが、他にわかりやすい言葉が無いのでそのままに。

Litecoin

ご存知ライトコイン。1期間は8046ブロック（2週間）と設定しており、時間的にはビットコインと同じですが、採用のための最低のSegwitブロックの採掘率は75%まで下げています。

#1145088（2月3日）からスタートして現在は3期間目です。当初は簡単にすぐ75%を超えるんじゃないかと言われていましたが、予想に反して現在は20%前後とビットコインよりも低い割合となってしまっています。

なかなか採用率が増えない一番の理由は、ハッシュレート占有率が40%を超えるライトコイン最大のマイニングプールのF2Poolの準備ができていないためだと思われます。ビットコインでも2番目のハッシュレートを占めているF2Poolは、ニュースサイトのインタビューなどでSegwitには前向きな姿勢だと度々答えていますが、技術的な理由で今年の春ごろまで出来ないというようなことも同時に回答しているので、時間の問題で数か月以内には75%を超えるかもしれません。

現在の状況は以下のようなサイトで確認できます。

Litecoin Segregated Witness Adoption Tracker

LiteCoin SegWit Adoption Stats

Vertcoin

ASIC対策特化のPoW型コイン。Lyra2REv2というMonacoinのハッシュアルゴリズムの借用元でもあるので、そこそこ有名なコインではないかと思います。実は2月8日にSegwit準備済みの新バージョンがリリースされ、Litecoinに引き続き投票期間が開始されるところだったのですが、新バージョンのクライアントのバグ（Segwitとは無関係）により事故的にハードフォークが発生し中止・ダウングレードを余儀なくされました。

その後再びバグ修正がなされ、3月1日にSegwit対応の新バージョンが出ています。1期間は2016ブロック（約3.5日）でしきい値は75%。投票はリリース同日（#675360）から早々にはじまり、現在は最初の投票期間中となっています。

投票状況を確認できるところが見つからなかったのでなんともいえませんが、ブロック情報を軽く見る限りでは最初の投票期間ですぐに有効化されるということはなさそうです。

追記：以下のサイトで見れるようになりました。

Vertcoin SegWit Activation

DEFINED（投票期間前）

Monacoin

近々投票期間が開始される日本発のMonacoin。同じく1期間は10080ブロック（約2週間）でライトコインと同じくしきい値は75%になっています。

投票は3月8日開始予定ですが、現在は海外のマイニングプールが主体となっており、アップデート情報が行きわたっていないのか、投票前では20%程度の投票率となっています。

Monacoinが早くSegwitを採用することになればなかなか面白いですが、悲しいことに海外の掲示板などでは全く話題にされていないので、静かに粛々と採用される感じになるかもしれません。

現在の状況は以下のようなサイトで確認できます。

Monacoin Segwit Status

Monacoin 新旧勢力割合図

ということで、実際にSegwit対応のバージョンがリリースされているのは4コインということになりました。アルトコインの数はあまりにも多いので調べ切れていないものもあるかもしれません。また、ここに書いていないものの中にもViacoinなど今後Segwit採用を明言しているようなところもいくつかあります。

ビットコインのSegwit投票状況が停滞している（＋ネットワーク大混雑状態の）今、他のコインに目を向けてみるのも面白いかもしれません。

NEMのNamespaceのレンタル期間を更新してみた

約1年前に作ったNEMのNamespaceのレンタル期間がそろそろ期限に近づいてきたので、更新してみました。Nano Walletに最近更新機能が実装されたので、記事にするまでもなく簡単なのですが、恐らくまだほとんどの人がやったことがないはずなので書いておきます。（ほとんどの人は手数料が下がった昨年の12月以降に借りているはずなので、更新する必要が出てくる時期には仕様とかUIは変わってるかもしれません・・・。）

1.画像の赤枠のところ、「Renew namespaces」を選択します。

2.ウォレットのパスワードを入力
3.「Renew」ボタンをクリック

4.完了!

これだけで終了です。ちなみにNamespaceの更新トランザクションはProvisionNamespaceTransactionという作成（借用）時のトランザクションと全く同じ型のようで、履歴にも作成時と同様の表示がされます。
現在の更新料は作成費用と同じ5000XEMですが、大本のネームスペースを更新すればサブネームスペースやモザイクも自動的に同時に更新され追加の費用を支払う必要はないようです。なお、寄付をいただいていたXEMが5000XEMを超えていたので、すべて寄付から更新料を出すことができました。ありがとうございました。

更新後はNamespaceの情報も更新されています。
更新前：

{"owner":"NBLK2AI3JONRZWVA57TC63W5UQ3JUD77MBXQWQES","fqn":"jpbit","height":511255}

更新後：

{"owner":"NBLK2AI3JONRZWVA57TC63W5UQ3JUD77MBXQWQES","fqn":"jpbit","height":1006151}

期限切れ一月前にならないと以下のように更新はできません。

Nano WalletのおかげでNamespaceの更新も非常に簡単にできたという話でした。

トランザクションがなかなか確認されないときの4つの解決策

ここ数日メモリプール（未確認トランザクション）の総サイズが60MB(blockchain.infoより)を超え過去最高レベルの混雑度になっています。ということで、手数料不足でトランザクションがなかなか確認されないときの解決法が、日本語サイト・ブログで意外と見つからなかったのでまとめておきます。

 １．待つ

ひたすら待てばいつか確認されるか、トランザクションがなかったことになりウォレットに残高が戻るかどちらかになります。一番単純な解決策で、初心者からどうしたらよいか聞かれたらとりあえず「待て」と言っておきましょう。

次からは事前に手数料を高めの設定にしてから送ってください。

２．RBF（後から手数料を変更できる設定にしてから送金）

詳細は過去のRBFの記事参照。Replace-by-Feeの略です。

事前にトランザクションに「このトランザクションは後から手数料が変更される可能性があるよ」とラベルを付けて送信することによって、送信後であってもあとから手数料を変更できます。

対応しているウォレットが非常に少ないのが難点で、主要ウォレットのなかで現在実装しているのはGreenAddress（GreenBits）とElectrumしかありません。公式クライアントBitcoin Coreも次バージョンの0.14からウォレットの機能としてようやく実装するようです。

３．CPFP（未確認トランザクションの確認を待たずに次の送金を実行）

Child Pays For Parentの略です。直訳すれば「親のために子供が（手数料を）支払う」といったところでしょうか。

ちょっとわかりにくいので例を出してみましょう。

Ａ→Ｂ

アドレスＡからアドレスＢにBTCを送信するとします。このときの取引手数料の設定が低すぎたためになかなかトランザクションが確認されません。そんなときにトランザクションの確認をまたずにさらにＢからCに送金を実行します。

Ａ→Ｂ→Ｃ

このとき、Ｂ→Ｃの手数料を十分多くすれば、マイナーは「A→Ｂ→Ｃ」を一連の取引と考え、Ａ→Ｂの取引手数料とＢ→Ｃの取引手数料の合計を「Ａ→Ｂ→Ｃ」全体の取引手数料と見なし、Ａ→Ｂの取引手数料が低かったとしても早めに確認してくれます。

 ただしこの方法には、わざわざ２取引分以上の取引手数料を余分に支払わなければならない点、自分が管理するアドレスへの入金トランザクションでないと実行できない点（ただし大抵の場合、「おつり」を自分のアドレスに送り返してるはずなので、意外と使える場面は多くあります。）などの欠点があります。どこか他人のアドレスに送ったトランザクションがなかなか確認されないというときには使えません。

また、一見「代わりにこっちで手数料支払ってあげるから手数料無料で送っていいよ」というような応用が効きそうな気がしますが、最初のA→Bの取引手数料があまりにも少なすぎると、そもそもノードからトランザクションが拒否されビットコインネットワークから直ちに除外されてしまうため、そのような応用はできません。

実際に行う時には以下の方法があります。

①未確認トランザクションを送金できるウォレット

そもそもそのウォレットが、未確認トランザクションによって送られてきたコインを確認を待たずにさらに送金できる必要があります。多くのウォレットでは対応していると思いますが、未確認トランザクションは結果的に確認されないリスクがありトラブルのもととなるため、デフォルトの設定では無効になっていたり、そもそもできないウォレットもあるかもしれません。

対応しているウォレットの場合、未確認トランザクションを含めた全残高をまとめてすべて自分のウォレット内のアドレスに送りかえすことでCPFPを利用することが可能です。要するに、全残高を使用すれば、必然的になかなか確認されない未確認トランザクションも含まれてCPFPになるということです。

お分かりのように、この方法はトランザクションサイズが大きくなり、それに伴い必要手数料が２取引分だけにとどまらずかなり大きくなってしまう可能性があります。入出金がかなり少ないウォレットでは使えるかもしれません。

②コインコントロール機能が使えるウォレット

コインコントロールというのは、どのUTXOを使うか、どのアドレスから送るかを選べる機能のことです。この機能も対応しているウォレットが非常に少なく、現在のところBitcoin CoreやElectrum、Armory等しかありません。

該当の未確認トランザクションのUTXOを使う取引を作成すれば、CPFPが適用できます。この場合は、2取引分だけの手数料で済みますし、自分のウォレットに送り返すことも、他の外部のウォレットに送って無駄な手数料を支払うことなく一度に済ませてしまうこともできます。

４．二重支払い

２のRBFのところで事前にRBFのマークを付けて送信しないと、後から手数料を変えられない・・・、と書きましたが、他の記事でも何回か書いているようにRBFもCPFPもマイナーやノードのローカルルールでしかありません。普通の取引であっても後から手数料だけを上げた二重支払い的な取引を作成・送信することで、後に送信された取引を確認させることが可能です。

当然と言えば当然のことながら機能として二重支払いが可能なウォレットはありませんが、自力で生のトランザクションデータを作成できる知識があればだれでも簡単にできますし、知識がない人でも英語で検索すれば腐るほど情報がでてきます。

RBFの記事では、サポートしているマイナーが少ないので成功する確率は低いと書きましたが、ハッシュレートの1%を占めているマイニングプールだけがサポートしていたとしても100ブロックに1回、つまり1日に1回を超える期待値で確認されることになります。

前の取引から間髪入れずに次の取引を送信しても、ノードから拒否されてマイナーまで伝わる可能性は高くないかもしれませんが、現状は経験的に1日程経過すればほぼ確実に二重支払いが成功するようです（時間が立つと一部のノードの再起動などによりメモリプールがリセットされたり、一部のメモリプール内の最低必要手数料が上がること等によりトランザクションが除外され、二重支払いの取引とは認識しないノードが増えます。）。

もちろん悪用すると犯罪行為になる恐れもあるので、自己責任で十分理解している人が必要な範囲で行ってください。

まとめ

ということで、ビットコインに慣れてきた人はただ待つだけではなく２や３（や４）の方法を試してみてはいかがでしょうか。

おまけ

２も３も４も面倒だから知り合いのマイニングプールに優先して確認してもらいたいよ、という人にはBitcoin Unlimitedを支持していることで有名になった？ViaBTCというマイニングプールが提供しているTransaction Acceleratorというツールもあります。このツールにトランザクションIDを入力すると優先度を高くしてViaBTCが確認してくれます。ViaBTCのハッシュレートの占有率は現在5%弱なので、20ブロックに1回、つまり3～4時間に1回程度の期待値で採掘されることになります。

なんでこんなことを無償でしているかというと、リンク先のツールを見れば分かるようにBitcoin Coreの開発チームがいかに悪くビットコインを駄目にしているかということを長々と説明しています。つまり政治的な主張の一環として無償でツールを提供しているわけです。

スパム対策のために0.0001BTC/kb以上、1時間に最大100トランザクションという制限があるため、人気が出てきたときは使えなくなりますし、Bitcoin CoreとBitcoin Unlimitedのコミュニティの分裂問題が何らかの形で決着するまでの期間限定だとは思いますが、特に抵抗がなければ利用してみるのもいいかもしれません。

シングルボードコンピュータでビットコインのフルノードを構築してみた

一つ前の記事でも少し触れましたが、ビットコインのフルノードをシングルボードコンピュータで構築してみたので、その手順を書きたいと思います。シングルボードコンピュータとはRaspberry Piに代表される超小型コンピュータのことです。

なお、今回のノード構築には今までにいただいた寄付を利用させていただきました。いつもありがとうございます。

０．機種選び

最低2,3年程度の常時安定稼働を目指しノードを構築することにしました。

本体

まずは本体のコンピュータ選びから。Raspberry Piが超有名ですが、メモリ1GBというのが不安でした。bitcoin.orgにもフルノードの最低動作環境は2GBとありますし、その他いろいろ調べてみると、ノード接続数を絞ったりして工夫すれば動くことは動くらしいのですが、長期安定稼働という点やネットワークへの貢献を考えれば貧弱スペックで無理やり動かすのはためらわれたので別の選択肢を探しました。

結果見つけたのが韓国のHardkernelという企業が作っているOdroid XU-4というコンピュータ。詳細スペックはリンク先を参照してもらえればいいと思いますが、最新機種のRaspberry Piと比較すると、CPUは8コア2GHz、メモリ2GB、eMMC対応、USB3.0対応、1Gbpsとかなり高性能です。ちなみにRaspberry Pi 3は4コア1.2GHz、メモリ1GB、USB2.0、100Mbpsという内容。

肝心の価格はOdroid XU-4が74ドル+22ドル（配送料+Paypal為替手数料）、Raspberry Piは35ドルなので、価格差はあるものの性能を考えれば妥当な感じ。

ちなみにOdroidは公式代理店のリストの中に日本の店が無いようなので、配送料が余分にかかりますが公式から直接買うのが良いようです。

Odroidの日本語記事はほぼ皆無で英語情報に関してもかなり少なかったので、実はRaspberry Piすら触ったことがない身としてはやや不安でしたが、結果からいうとインターネット上に転がっているRasperry Piの情報を頼りにほぼ同様にセットアップできましたし特に大きなトラブルもなかったので良かったです。

ただ、やはり情報も使用ユーザーも少ないですし、トラブルがあったときは英語で問い合わせなければならず公式サポートの評判も怪しいので、慣れていない人にはあまりお薦めできません。

ストレージ

普通はマイクロSDカードを使用しますが、フルノードは容量も要求されますし、かなり頻繁にディスク書き込みがあることを考慮して、HDDを利用することにしました。今後ブロックサイズが上がることも考慮して1TBのものを購入。剪定モード(Pruning mode）で運用する人は容量的にはほとんど必要ありませんが、SDカードだとやはり寿命が心配な気がします。

ディスプレイ

ただビットコインノードを運用するだけでもいいのですが、正直それだけだと面白くないのでコンピュータの情報を表示するLCDディスプレイを取り付けることにしました。OdroidにはCloudshellという、2.5インチHDDの取り付けが可能なNAS用のちょうどいいディスプレイ付きケースが販売されているので購入。Odroidを選んだのも実はこのCloudshellに惹かれてと言うのが大きいです。

まとめ

思ったより高くついてしまいました。合計約24,000円です。一部ビットコインデビットカード（プリペイドカード）を使用したので、手数料等で実質にかかったコストは計25,000円程度。

本体部分

• Odroid XU-4：96ドル（本体+配送料等）
• 2.5インチHDD 1TB：5570円
• マイクロSDカード 8GB：518円
• LANケーブル（CAT6）：326円
• 計：約17200円

基本HDDを使用しますが、ブートローダー（起動用プログラム）にはSDカードを使用しなければいけないようのでマイクロSDも購入。容量は必要ないものの、最低クラスでも値段はほとんど変わらないので8GBのものにしました。いらないSDカードが家に転がっている人はそれでもいいと思います。

ちなみに今回は使用しませんでしたが、CPU8コアをフル運用するとかなりCPU温度が熱くなるので、特に夏場は使用コア数を制限するか追加でファンを取り付けることが必要になるかもしれません。CloudShellにはサイドに40mmのファンを取り付けられるようになっています。

ディスプレイ部分

• CloudShell for XU4：39ドル
• 電源アダプタ（5V/6A）：2230円
• 計：約6600円

Odroid-XU4にも標準で5V/4AのACアダプタがついてきますが、CloudShellを使用する場合、それだと足りないらしいので、いろいろと探してAmazonで5V/6Aのものを購入。Odroid公式でも売っていますが、PSEマークがついてないらしいので、値段はあまり変わりませんし日本で購入したほうがいいかもしれません。

１．OSイメージをダウンロード

適当なPCからOSイメージをダウンロード。Odroidの公式wikiにXU4用のUbuntuが置いてあるので、最新のUbuntu16.04をダウンロードしました。

２．OSイメージをSDカードに書き込み

ダウンロードしたOSをSDカードに書き込み。方法は検索すればいくらでもでてくるので省略。

 ３．CloudShell（ケース）の組み立て、起動

公式ページを参考にケースを組み立てます。組み立てが終わったら、SDカードやLANケーブルを接続して起動します。今回は使用しませんでしたが、HDMI端子もついているので必要な人はディスプレイにつないでも良いです。

４．SSH接続

ディスプレイ無しでセットアップしたので、ローカルIPを適当に探して他のPCからSSHで接続。同じく方法は省略。

５．HDDで起動するように設定

セキュリティ設定する前にHDDのみを使用するように設定。方法は省略。

６．セキュリティ設定

24時間自宅サーバーを公開するのはいろいろと危険なので、セキュリティ設定にも気を遣う必要があります。SSHのポート変更、rootログイン禁止、パスワードでのログイン禁止、公開鍵認証の設定などが最低限。その他必要に応じて設定してください。方法は省略。

７．LCDディスプレイの設定・表示

公式wikiに設定方法が書いてあります。CPU使用率やメモリ使用率を表示できるサンプルスクリプトも用意されているので、フルノードの起動前に設定・表示しておくと便利かも。

ちなみに初期状態だとスクリーンセーバーのような感じで起動後しばらくして画面が真っ黒になるのでさらに設定を変更する必要がありました。ここが一連のセットアップの中で一番悩みましたが、/media/boot/boot.ini内の、setenv bootrootfs "console...と続く行に「consoleblank=0」を追加したら常時ディスプレイが表示状態になりました。

８．Bitcoin Coreのインストール

いよいよBitcoin Coreのインストール。普通にソースコードからビルドする方法と、PPA（非公式レポジトリ）からインストールする方法の2種類があります。PPAはインストールやバージョンアップが非常に簡単というメリットがあります。ただし、デメリットとしてUbuntu以外のOSは使えない、バージョンアップの際に更新が遅くなる可能性がある、その他やや信頼性に欠けるという点もありますが、幸いなことにUbuntuを使用していたのと、Bitcoin CoreのPPAの管理者はBluemattというコア開発者の一人ですしかなり利用者も多く信頼性はまあ十分と考えて、今回はPPAを利用しました。

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

 この三行でインストール終了。GUIウォレットの画面を利用したい方は「bitcoind」だけではなく「bitcoin-qt」もインストールしてください。

９．OSやBitcoin Core等のチューニング

フルノードのためのチューニング。まずはメモリのスワップ領域が全く設定されていなかったので、4GBほど設定（たぶんそんなにいらないです）。最初は何もやらずにノードを起動したんですが、起動後メモリ使用量が95%を超えていたために今回は後から設定しました。ちなみに同期中のスワップ領域の使用容量は200MB程度でした。その他にもいろいろあるかもしれませんが、ここらへんは全く詳しくないので何もいじってません。

それからBitcoin Coreの設定ファイル（bitcoin.conf）を設定します。なにも設定しなくても動くので、必要に応じて設定してください。Raspberry Pi等の場合、メモリがかなり厳しくbitcoindが落ちる可能性があるので、いろいろと絞ったほうが良い場合があります。以下のページが参考になります。

Reducing bitcoind memory usage · GitHub

ちなみにOdroid XU-4もCPUがかなりオーバーヒート気味になるので、par=1などで使用コア数を制限したりする必要があるかもしれません。今回は何も設定しませんでしたが、同期中に一回だけbitcoindが落ちました。CPUが原因かメモリ不足が原因かは不明ですが、メモリのスワップ領域を設定後は落ちなかったです。

１０．Bitcoin Coreを起動、同期を待つ

bitcoind -daemon

で起動し、同期するのをひたすら待ちます。Odroid XU-4では2017年2月時点（約120GB）で同期完了まで丸8日かかりました。今回はテストの目的がありましたが、現在は最新のPCなどスペックによっては1日もかからず同期が終わるらしいので、別のPCで同期させてからノード本体機に移動させたほうが良いかもしれません。

ちなみに昔はbootstrap.datなどをtorrentなどでダウンロードする方法もありましたが、現在ではダウンロード速度というよりもブロック、トランザクションの検証速度がボトルネックらしいので普通にBitcoin Coreから起動するのが一番いいらしいです。

 ビットコインノード用にディスプレイ表示をカスタマイズ

サンプルの表示プログラムもCPU使用率等が表示され便利ですが、やはりビットコイン用にノード接続数とかメモリプール、未確認トランザクションのデータなどを表示したいのでプログラムを改変。プログラムはシェルスクリプトになっています。

以下に置いておきますが、スクリプトとしてコマンドを書いたことはほとんどなかったので微妙なコードになってるかもしれません。必要に応じてコードをいじってパラメータを変更しなければならない場合もあるので、少なくともコードを読める人向けです。

GitHub - bitkatana/cloudshell_lcd_bitcoin: ODROID-XU4 Cloudshell LCD Informations for Bitcoin Node

同期中の表示はこちら。

詳細はGithubのページに書きましたが、ビットコイン関連のデータだけ軽く解説。実はブロックの検証中はbitcoin-cliコマンドにほとんど反応せず数十分かかるとかタイムアウトするとか問題があるので、ブロックチェーンの同期中は停止しておいたほうがいいかもしれません。

 ノード接続数

ノード接続数をBitcoin Connectionとして表示しています。「bitcoin-cli getconnectioncount」で普通に取得できます。画面だと61とかなり多めになっていますが、Torで接続するとこんなに行かないと思います（画面はTorのIPになっていますが、同期中は普通に接続していました）。接続数が増えるほど負荷が高くなるので、bitcoindやコンピュータが落ちる場合はmaxconnectionをbitcoin.confで制限するのを推奨。

最新のブロック

「getblockcount」で最新のブロック番号を表示。それから「getblockhash ブロック番号」でブロックのハッシュ値を取得し、さらに「getblock ハッシュ値」でブロックの生成時刻を取得します。現在時刻も取得し、「現在時刻－ブロックの生成時刻」でどれぐらい前のブロックか表示しています。

ちなみにブロックチェーンが同期状態にあるかは、blockchain.info等のブロックエクスプローラー（つまり他のノード）のブロック番号と比較する方法もありますが、Bitcoin Coreでは単純に最後のブロックが90分以内だと同期状態と判断するようにGUIウォレット上では表示しているようです。

メモリプール情報

「getmempoolinfo」でメモリプール（未確認トランザクションの保存領域）に関する情報が取得できます。上の方に表示しているmempool usageが実際のメモリの占有領域、下のほうが未確認トランザクションの数とサイズです。写真上では同期中なので、メモリプールには何にも入っておらずゼロ表示です。

手数料予測

「estimatefee 6」で手数料の予測値を表示しています。estimatefeeの後ろはブロック数を表し、この場合は6ブロック（約1時間）以内に確認されるのに最適な手数料を表示するような設定です。

メモリプールから計算するので同期中では計算ができず-1が返されます。ちなみに、Bitcoin Core 0.14からはデフォルトの値が6になるらしいので、ここでも6にしています。最低値は2で、1にすると計算できないので必ず-1が返されます。

価格情報

取引所のAPIにアクセスして最新価格を取得しています。どこでもいいですが、とりあえずbitflyerとbitfinexのAPIを利用させていただきました。

 １１．同期完了

ということで同期が完了しました。同期中の写真からちょっとスクリプトをいじって表示を変えました。同期後はメモリプールや手数料予測の情報も表示されます。

単なるフルノードだと面白くないし実用性に困りますが、メモリプールや手数料情報、価格情報も表示するとなかなか使えるのではないでしょうか。

 １２．（オプション）Torとしてノード運用する

IPを隠したい場合や不足気味なTorノードとして運用したい場合はまずTorをインストールします。Torの公式ページにインストール方法があるのでそちらを参照すると良いでしょう。Option1は最新バージョンが入らないらしいのでOption2でインストールするのがおすすめです。

インストールしたら設定ファイルの/etc/tor/torrcを開き以下の行を追加します。

HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333

 再起動後、

cat /var/lib/tor/bitcoin-service/hostname

 でビットコインノード用のIPを確認します。

さらにbitcoin.confに以下の行を追加します。

onlynet=onion
onion=127.0.0.1:9050
listen=1
bind=127.0.0.1:8333
externalip=yourip.onion

 externalipのところはcat～で確認した自分のIPを入力してください。

ちなみにこの設定だとIPが固定になり、Torネットワーク以外の普通のノードには接続しないようになっています。

動的IPや匿名性ではなくネットワークの貢献のための運用で一般ノードにも接続したい場合は以下のページが参考になります。

bitcoin/tor.md at master · bitcoin/bitcoin · GitHub

Setting up a Tor hidden service - Bitcoin Wiki

１３．（オプション）どこからでも自分のフルノードに接続してウォレットを使う

前回の記事で書いた通り、フルノードにはセキュリティ（は現実的にSPVとほとんど変わりませんが）、プライバシーが優れているというメリットがあります。今後SPVウォレットのプライバシーも改善される可能性はありますが、現状だといろいろと問題があるらしいので信用できる自分のフルノード以外と通信しないようにすれば大きなメリットとなるでしょう。

残念ながら現状はAndroid用のBitcoin Walletにしか対応していません。同ウォレットの設定メニューからIPアドレスを設定すれば完了です。

ただし、ビットコインの通信というのは実は全く暗号化されていないので、Torを使わないと通信を傍受されて簡単に内容を読み取られる恐れがありあまり意味がありません。プライバシーが気になる方は通信内容を暗号化できるTorを使いましょう。AndroidにOrbotというTorアプリをインストールすると通信できるようになります。

ただし、TorはTorでいろいろと問題があるらしいですし、第三者のソフトに頼るのはあまり良くないので、SSL通信ぐらい実装してくれと思います。ここらへんはBIP150/BIP151で信頼できるノードの認証方法や暗号化通信が提案されており、前向きに検討されているようなので時期は不明ですが今後の実装に期待というところです。

最後に

ということでビットコインのフルノードを構築してみました。ビットコインのプライバシーというとビットコインアドレスの非匿名性が話題に上がるのが普通ですが、軽量型ウォレットの通信のプライバシーも大きな課題の一つであり、フルノードをたてれば軽量型ウォレットから信頼できる自分のフルノードに接続することでその課題がある程度解消されます。

同期中はかなり負荷が高くなりますが、同期後は安定しており負荷も低いようなので、今後はスペック的にできるかどうかわかりませんがElectrumのサーバーでもたててみようかと思います。

Bitcoreという、ブロックエクスプローラーやCopayで利用できるウォレットAPIが使える（つまりCopayから自分専用のフルノードだけに接続できる）便利なライブラリもあるのですが、やる気がないのかもともとこんなものなのか、いまだに最新のBitcoin Core 0.13系には対応していないようなのでとりあえずは見送ります。Bitcoreに関しては、日本語でもかなり情報が多い印象なので気になる人は検索すると良いでしょう。

どちらにしてもBitcoin Core上でBitcoreとかElectrumサーバーとかCounterpartyとかさらにいろいろとやりたい人は、txindex=1オプション等をbitcoin.confとかに書いてトランザクションにインデックスを付けなければならないので、最初に忘れずに設定ファイルに書いておきましょう（今回忘れたので、再度長い日数をかけてreindexしなければいけなくなりそうです・・・。）。

※BitcoreやCounterpartyはトランザクションだけではなくアドレスなどにもインデックスを付けなければならず、そのために別にBitcoin Coreへパッチをあてる必要があります。