イーサリアムのおすすめPC用ウォレット（2016年9月時点）

当ブログでは、MistやらMyEtherWalletやらイーサリアム用のウォレットについて、触れてきましたが、最近のアップデートによりMyEtherWalletはかなり進化しており、機能的にはMistと変わらないレベルになっています。

回しものではありませんが、今のイーサリアムウォレット（PC用に限る）のおすすめは公式のMist（Ethereum Wallet）ではなくずばりMyEtherWalletであると断言して簡単に説明を書いていきます。

インストール方法

前に少し触れましたが、やはりmyetherwallet.comにアクセスするのではなくソースコードをダウンロードして実行するのが良いと思います。

GitHub - kvhnuke/etherwallet at gh-pages

最近できたのか見落としていただけか分かりませんが、上のリンクから画面右部の緑ボタン「Clone or download」→「Download ZIP」を選択することにより、必要なファイルだけをまとめてダウンロードできます。（前の記事で紹介したときはChrome拡張機能版など不必要なソースコードも同時にダウンロードするものでした。）

使い方はビットコインなどに触れたことがあれば恐らく直観的に分かると思うので、申し訳ないですが省略します。

Mistとココが変わらない

必ずしもMyEtherWalletの使用をおすすめできなかったのは、単純にMistを使わなければならない場面が多く存在したのも大きい理由の一つです。現在ではそういう場面はほとんどなくなった気がします。

①日本語対応

最近のアップデートで日本語対応しました。index.htmlを開いて右上から選択できます（初期状態は「English」）。英語が苦手な人でも使えるようになりました。

②独自トークンが使える

Mistと同様にEthereum上で作成されたトークンを自由に表示・送信できるようになりました。「Send Tokens（トークン送出）」タブからアカウントを開いた後、「Custom」欄を選択しコントラクトアドレスなどを指定することで、トークンを自由に追加できます。

例えば、前はDAOやDigixなどごく一部を除いては、ICOで購入したりして入手した様々なトークンを表示するにはMistを利用しなければなりませんでしたが、現在ではMyEtherWalletで扱えます。

③スマートコントラクトを実行できる

「Deploy Contract（コントラクトをデプロイ）」タブからスマートコントラクトコードを実行（ネットワークに送信）できるようになりました。現実問題、一般ユーザーが利用することはほとんどないと思われますが、これで実質的にMistと遜色ないレベルになったと言えます。

ただし、コードを書いたりはできないので、スマートコントラクト関係をいじろうと思うと、MyEtherWalletでは微妙かもしれません。

Mistよりココが優れている

①生の秘密鍵をバックアップできる

ウォレットを作成すると、暗号化されたKeystore/JSONファイル以外にも生の秘密鍵が表示されます。普段使いは暗号化されたKeystore/JSONファイルのほうが良いでしょうが、緊急時のバックアップの際などは生の秘密鍵を紙ベースなどで保存していると何かと安心です。

秘密鍵が晒されるということである意味弱点にもなり得ますが、紛失リスクと盗難リスクを天秤にかけた場合、個人的には概して利点と言えるのではないかと思います。（ちゃんとリスクは理解して使いましょう。）

②オフライン取引ができる（コールドストレージとして利用できる）

MyEtherWalletでは「Send Offline（オフライン送出）」タブから、取引をオフライン環境下のPCで作成した後、オンライン環境のPCに移してネットワークに送信できます。通常のユーザーはほとんどこの機能を使うことはないでしょうが、うまく使えばMistより安全に使用することも可能です。

③同期を行う必要がない

ある意味ここが最大の利点です。ウェブ上から直接利用しようが、ローカルにダウンロードして利用しようが、膨大なブロックチェーンをダウンロードする必要がありません。しかし、外部サーバーなどに頼るということも意味するので、セキュリティ的には微妙かもしれません。

Mistは何がいい？

ではMistは何が良いのでしょうか？

１）公式ソフトである

最大の利点その1。開発者は名の知れた人で関わっている人数自体も多いです。MyEtherWalletはオープンソースですし、すでに公開から1年以上経っておりかなり多くの人が使っているので、実用には問題ないレベルだと思いますが、信頼性の面で大きく負けます。

２）ブロックチェーンをダウンロードする

最大の利点その2。外部に頼らず自前でブロックチェーンをダウンロードするのは、やはり安心できますしセキュリティ的に考えても良いです。ただし、利便性はもちろんセキュリティを考える上でも様々な要素がありますし、ウォレットファイルの紛失リスク、破損リスクなども考慮すると、ビットコインウォレットとしてBitcoin Coreをおすすめしないように玄人を除いてはMistもやはりあまりおすすめはできません。

３）DAppsブラウザとして

混同されて使われていますが、正確に言えば、実はMistはDApps（分散型アプリケーション）ブラウザのことであり、ウォレット自体はEthereum Walletという名称です。（Ethereum Walletという名称が一般的すぎて固有名詞とわかりづらいので、ここでは分かりやすくするため逆に混同して使っています。）

MistのGithubのダウンロードページを見てもEthereum WalletとMistで分かれてると思います。現時点では残念ながらまともに使えるDAppsは皆無ですし、MistにもEthereum Walletが内蔵されているので、どっちをダウンロードしても対して変わらないのですが、将来的にDAppsがリリースされるようになったら単なるウォレット用途ではなくDAppsブラウザとしてMistを使う場面も来るかもしれません。

まとめ

MyEtherWalletで作成できるKeystore/JSON形式のウォレットは公式ウォレットMist（Ethereum Wallet）にも対応しており簡単にインポート可能で、MyEtherWalletで作成したアカウントでトークンやらを受け取ってもなんとかなります。もしかしたら、Mistを使用しなければならない場面がくるかもしれませんが、迷った時はとりあえずはMyEtherWalletを試してみてはいかがでしょうか。

最近よくある仮想通貨の投資話からICOについて改めて考えてみる

なかなか個別の案件を見る時間がなく全然追いついていないのですが、最近もICOを行うプロジェクトが次々と出てきており各所で話題にもなっているようです。もしアドバイスを求められたら、この手のスタートアップは、仮想通貨業界に限らずほぼ確実に将来潰れてごく一部しか生き残らないので、とりあえず失敗して10年後には無くなっている、とでも言えば大体当たると思います。

しかし、こんなICOでもまだましだと思うことがあります。それは、最近身近なところでもしばしば耳にする仮想通貨の投資話です。仮想通貨に関する話題が一般にも広まってきたのは喜ばしいことかもしれませんが、その裏で詐欺も広まるということは好ましいことではありません。実際のところ詐欺の証拠を掴むのはとても難しく、詐欺かどうかはわからないのですが、一般的なICOのスキームと比較すると非常にお粗末なものなのです。そのため、身近な投資話に惑わされそうな人の説得や、勧誘をしてくる不届きもの相手には詐欺と言って一蹴するのではなく、単純に失敗する可能性が高いと説得する方が相手の心には響くかもしれません。

そもそもICOとは何か

Initial Coin Offeringの略で株式の世界のIPO（新規公開、Initial Public Offering）に対応するものです。ICOではそのコイン、仮想通貨の開発者が新しく発行したコインを売りに出すことで、プロジェクトの資金調達を行うことになります。

IPOになぞらえられていることからコインがプロジェクトの株式に例えらえることもよくありますが、プロジェクトによっては、送金手数料としてしか利用できなかったり、何らかの投票が可能で議決権を持っていたりいなかったり、あるいは持っているだけで配当のようなものがあったりなかったり、性質は様々で株式と必ずしも一致するものではありません。

利用者としては、むしろクラウドファンディング的なものをイメージしたほうが良い場合が多いと思われます。

そもそもProof of Workでコンピュータによる採掘・発行が可能な仮想通貨以外は、すべてIPO的な形態を経て利用者に仮想通貨を配布しなければなりません。逆にICOを行わない仮想通貨というのは、Proof of Workしかないと言えるでしょう。（Proof of Workであっても事前採掘を行いICOによりユーザーにコインが配布されることもあります。）

一般的なICOの特徴・傾向

ICOにおいて重要視されるのは、①公平性と②透明性の２点です。②の透明性は正直微妙なものもかなり多いのですが、特に公平性というのは仮想通貨の世界でかなり重要だと考えられています。

例えば、当時機能だけを見ればMastercoin（Omni）のクローンでしかなかったCounterpartyは公平・透明なICOとしてProof of Burnにより配布を行ってアピールし、すぐにMastercoinを追い抜きました。Proof of Work型のMoneroも公平なスタートをアピールして、クローン元そのものであったBytecoinを追い抜きました。

（もっともこれらはその後の開発状況が優れていたのも大きな成功要因だと思われます。）

スタートが不公平であったと言われるDashやNxtは失敗とは言えないものの、常に不公平という批判にさらされ続けています。

中には公平性や透明性の観点から、事前採掘されているコインはすべて詐欺、ICOを行うコイン（≠Proof of work）はすべて詐欺、とまで言う人もいます。

 お粗末な仮想通貨の投資話の例

しかし、上記の（海外の仮想通貨コミュニティを見れば）常識的なことを全く知らないとしか思えないさらに残念な投資話も最近は横行しています。

また、ブロックチェーンの利点をほとんど無視している話も多くあります。ICOは個人で世界中どこにいても少額から参加できるというのが良い点であり、これらの特徴を無視するからには相応の理由をきちんと説明してほしいものです。

地域限定販売

よく見かけるのが日本だけ先行販売という手法です。もし、地域通貨としてのプロジェクトならばアリだとは思いますが、そうでなければ意味がよくわかりません。世界規模で成長をしていきたいのなら公平性という点で大きな弱点を抱えることになるでしょう。

世界中どこからでも一瞬で送金できるというブロックチェーンの利点を無視しており、馬鹿にしてるとしか思えません。

宣伝場所が限定的

この手のお粗末な投資話はセミナーが一般的であり大抵bitcointalkなどの主要コミュニティでは宣伝されていません。一部でこっそりとICOを行うやり方は忍者ローンチ（ninja launch）と呼ばれ公平性を損なうため嫌われる手法の一つです。

ごく一部の人の間だけで流通させたい特殊なコインならいいのですが、世界展開したいなら大きな弱点です。

購入金額に最低金額が設定されている

ブロックチェーンの利点は世界中のどこからであっても1円でも低手数料で送金できるということにあります。それに対応するかたちで一般的なICOでも最低金額は設定されていないのが普通です。数百円とかならまだしも最低○万円などというのは論外です。

必ず値上がりすると宣伝されている

この世に永続的に必ず値上がりする仕組みというものは残念ながら存在しません。もしポンジスキーム（自転車操業）のように必ず儲かる仕組みが入っているなら、そのあとに必ず破綻する仕組みが含まれているということを示しており、逆に危険であると自ら宣伝しているようなものです。

ビットコインも必ず値上がりすると宣伝されることがよくありますが、実際はそうではないのでそうやって勧誘するのは正直どうかと思います。また、気持ちはわからなくもないですが、最近はまじめにやってそうなところでも運営側・開発側でコインの売買を煽るようなコインもしばしば見られ、外から見てる側からすると印象が悪くなるだけでは？と思ってしまいます。

一番恐ろしいのは「普通の」ICO

明らかに詐欺っぽいプロジェクトや失敗しそうなプロジェクトはまだ良いのですが、最もひっかかりやすいのが「普通の」ICOです。過去の一見真面目なプロジェクトもICOだけやってほとんど消息不明であったり、1年2年と経っていまだにスタートしてない、トークンを受け取れないというものも数多くあります。

詐欺だろうがそうでなかろうがICOの非常に大きいリスクはトークン配布が実際行われるのかわからない、あるいは配布が行われた時点の価格が全く不明という点です。ハイリターンかもしれないがハイリスクのICOに参加するか、あるいは公開後にいつでも売買可能な取引所でトレードするか、ちゃんとリスクを認識して投資するようにしましょう。

Segwitの次の可能性（シュノア署名・MAST）

最新バージョンのBitcoin Coreに組み込まれ、次バージョンには有効化かと思われるSegwitですが、トランザクション展性やスケーラビリティ問題への対策だけではなく、新技術の実装が容易になるという大きなメリットもあると言われています。

これは、分離された署名の格納領域であるwitnessの中にスクリプトのバージョンを記述する欄が導入されるためです。

そもそもビットコインはトランザクション内に記述されたスクリプトを元に動作しており、そのスクリプトによって通常の送金取引だけでなく、様々な処理を実行することができます。ビットコインのスクリプトは、イーサリアムのようにチューリング完全ではないので、できることには限りがありますが、例えば、OP_CHECKLOCKTIMEVERIFYという処理を使えば、一定期間使用できない凍結されたBTCを送ることもできます。また、OP_RETURNという処理を使えばその時点でスクリプトを停止して後ろに任意のデータを挿入することができるので、その任意のデータを元にCounterpartyやFactomなどをはじめとして数多くのビットコイン上のプラットフォームが構築されています。

これまでスクリプトや署名に関する仕様を変更するのはかなり困難でハードフォークが必要となる場合も多いと考えられていましたが、Segwitにより導入されるwitnessにより今まで困難だった仕様変更が容易になると言われているのです。

Schnorr signature（シュノア署名）

中でもSegwitにより期待されているのがSchnorr署名という新しい署名方式の導入です。

ビットコインにおいて署名というのは根幹的な役割を果たしており、BTCの所有権を証明するために利用されています。署名はプライベートキー（秘密鍵）を利用することにより取引データから作成され、取引データから作成された署名は公開鍵（アドレスの元）により正しいものであると誰でも確認できます。正しい署名と一緒に「AからBに1BTC送る」というトランザクションをネットワークに送信すれば、Aの秘密鍵の所有者が送金処理を実行したとAの秘密鍵を知ることなく誰でも確認できることになります。

一般的に署名の方式には様々なものがあり、ビットコインではECDSAという方法が利用されています。このECDSAに変わる署名方式として提案されているのがSchnorr署名という方式です。

Schnorr署名は数ある署名方式の中でも最もコンパクトな署名であり、署名検証のスピードもECDSAより速いと言われています。

Schnorr署名は、複数の署名を一つに統合できるのが大きな特徴です。多くの場合、ビットコインのトランザクションは複数の「入力（input）」から成り立っています。Blockchain.infoなどのブロックエクスプローラーを見れば分かると思いますが、複数のアドレスから同時に送信する場合もそうですし、一つのアドレスから送信する場合もしばしば入力が複数になることがあります。

（ここらへんはUTXOという基礎知識があれば理解できると思います。）

このような場合、一つ一つの入力それぞれについて、署名を同時に添付する必要があります。そのため、署名の分だけサイズが大きくなってしまうのです。サイズが大きくなるということは、取引手数料が高くなるということを意味します。Schnorr署名では、これらの署名を一つに統合することができます。多くの署名が一つに統合されるので、サイズ的に非常にコンパクトになるのです。

Schnorr署名は通常の送金だけではなく、特にマルチシグネチャでの送金に大きな利点があります。マルチシグネチャアドレスでは複数人の署名を必要としますが、Schnorr署名を利用すれば一つの署名の統合できるので、大きくサイズ削減を行うことができます。

署名のサイズが小さくなればトランザクション全体のサイズも小さくなり、スケーラビリティ問題に対する大きな対策になるというわけです。

Schnorr署名はサイズをコンパクトにするという目的が大きいですが、セキュリティ面から考えた新しい署名方式の導入も一部では推されています。

しばしばビットコインは量子コンピュータが実用化されたら崩壊する（例えば公開鍵から秘密鍵を算出できるようになる）と言われることがありますが、これも新しい署名方式の導入により防げると考えられます。Lamport署名という署名方式は量子コンピュータに対して耐性があると言われており、特に有効だと考えられています。ただし実際には、Lamport署名自体に欠点が多く存在し、現段階でのビットコインへの実装はあまり現実的ではありませんが、従来のECDSA自体にセキュリティ上の懸念があっても、今までより簡単に署名方式を変更できるようになったのは大きいと言えるでしょう。

MAST（Merkelized Abstract Syntax Trees、マークル化抽象構文木）

もう一つスケーラビリティ問題への対策になると考えられているのが、MAST（マークル化抽象構文木）という技術です。

現在のビットコインのスクリプトは、scriptPubKeyと呼ばれる欄に送信者が直接記述する方式となっています。しかし、現在のスクリプトシステムにはある程度サイズ制限があることや、スクリプトの内容がすべて全世界に公開されてしまうというデメリットも存在します。

MASTではビットコインのスクリプトの条件処理の部分ごとに分割し、それぞれをマークル木（各データをツリー構造にハッシュ化して短くまとめたもの）として統合しようとするものです。

これによりサイズ削減できるだけではなく、ツリーの一部の枝部分のみを実行して、残りの実行しない部分はハッシュ化されており第三者から見えないという意味でプライバシー保護にもなります。例えば、Aさんが通常の送金処理の他に「もし一年間使用しなければ、BさんにBTCの使用権を引き渡す」というスクリプトを添付して送信したとします。このとき、後半のスクリプトはハッシュ化されており、第三者には一切見ることができません。

条件処理を使うような複雑なスクリプトはあまり使用されていないのが現状ですが、今後広く使用されるようになればメリットの大きい技術だと考えられます。（プライバシーの観点から使用可能性が増えるとも考えられます。）

このMASTもSegwitにより導入されるwitnessを利用することで今までより容易に導入することができます。

参考リンク

Bitcoin Core :: Segregated witness: the next steps

bitcoin.orgに警告文が掲載、Bitcoin Coreが改ざんされていないか検証する方法

ビットコインの公式クライアントであるBitcoin Coreの新バージョン0.13.0が数時間前にリリースされました。このバージョンではSegwitのコードが初めて含まれることとなりますが、コードが含まれているだけでまだ有効化はされていないので、実質的なSegwitの実装は0.13.1になるものと思われます。

ところで、0.13.0のリリースの数日前にbitcoin.orgに謎の警告文が掲載されました。主な内容は、国主導（中国政府？）のアタッカーがBitcoin Coreのバイナリ（実行ファイル）を攻撃する恐れがあるから注意してダウンロードして使用するように、というようなものです。ただし、この警告文はbitcoin.orgの共同管理者の一人であるCobraという人の一存で勝手に掲載されたもので、表立ってなにか脅迫文なようなものが送られてきたというような情報は一切明らかになっておらず、なぜいきなりこのような警告文を乗せたのかは不明です。

とはいえ、仮に脅迫のようなものがあってもなくても常にbitcoin.orgのようなウェブサイトがハッキングされてBitcoin Coreの実行ファイルが改ざんされる恐れは常にあるので、この記事ではダウンロードしたファイルが改ざんされていないかどうかを検証する方法を書きたいと思います。

実際にここまでやっている人はほとんどいないですし、通常のユーザーは検証する必要もないと思いますが、ハッシュを計算したり電子署名を検証したりとビットコインの基礎的な技術とも関係するので暇なときに試しても面白いと思います。

（お金が直接関係するソフトなので理想を言えばやったほうが良いですが、手間を考えると非現実的なので、更新直後にダウンロードするのではなくしばらく待ってから何らかのトラブルがないか身近なコミュニティで確認した後にダウンロードすると良いでしょう。）

なお、記事を書いている時点ではBitcoin Core 0.13.0のビルド（ソースコードから実行ファイルを作成する手順）後のものがまだ公開されておらずインストーラー等は準備されていないので、0.12.1を例にします。

①Bitcoin Coreをダウンロード

好きなところから自分のOSに合ったBitcoin Coreをダウンロードします。Bitcoin.orgでは以下のURLにまとめて保存されています。

https://bitcoin.org/bin/

②署名をダウンロード

ダウンロードしたソフトが改ざんされていないことを証明する署名をダウンロードします。先ほどのURLにある「SHA256SUMS.asc」です。

ファイルをメモ帳などで開くと、以下のようにBitcoin Coreのファイルのハッシュ値が署名に添えて書かれていることが分かります。

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

abf0e7336621250702d7a55487c85b8de33c07a30fbc3ecf7f56c97007fcb4ce  bitcoin-0.12.1-linux32.tar.gz
54aca14b7512801ab78cc93f8576e1b66364a890e8017e8a187e4bf0209fd28c  bitcoin-0.12.1-linux64.tar.gz
91d14dcb9b88ca845df450ceb94250bb5c9a0d514d8ca0c55eb480d0ac77ef32  bitcoin-0.12.1-osx64.tar.gz
e1bc86d24dd978d64b511ada68be31057c20789fb9a6a86c40043a32bf77cb05  bitcoin-0.12.1-osx.dmg
08fc3b6c05c39fb975bba1f6dd49992df46511790ce8dc67398208af9565e199  bitcoin-0.12.1.tar.gz
fba73e4825a6421ce6cc1e48b67ff5f2847ae1b520d26272e69f7f25de4f36d1  bitcoin-0.12.1-win32-setup.exe
148fb438a32f1706a366a7825bbc5e770e5f9a20e5694f724a443275976a0791  bitcoin-0.12.1-win32.zip
c6e06f90e41c36c9a447f065952869e2d7d571ab34b86d061ae19ec25b2799d4  bitcoin-0.12.1-win64-setup.exe
d8e1ab9ff65b79c130ec6af8e36626310ffdaf6aacb7a40cfb76e7a63bdfcfd5  bitcoin-0.12.1-win64.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJXEIwgAAoJEJDIAZ42wulkXNcP/Re0iawPi8muiq6J36ZUZKws
KL2nwjCImj91on8wGoTUir1IytuIafA4JMHslos2Ak3za2UKAEZrEfx0dXm/FVql
AgRneYLYedMQ8127UkSho4rxuwjB3h2gR/FGPpPT0PmbNTWOFsKtV1V9zwsCeA9Q
br/ly2BfZHWsS1tpSK5ukP5W0q+Ii2fO4pcfaAsS2y/gc5kyj5hTiKQivwBVXoVA
cyH1splq1foM5BYwOuT/cUKGrpA8fWo7+xOaEhhFBlW0oJaSXcNSK9mVTSI/dQ/2
lINXcWBtotnH6/evS35pAIOe4PHg/URhXNT/Sdfwts4YL5nMtF+SPBrJWadPvx3C
qdSDZKMuM0cDjVg1F4rjoWAxyshWNKKU2J+qkNUBZ1LbpVyDR3Gl4LFwRjaw0wyZ
n6zHonPCtp33ErhsaY0GryHV1pKvL1h6uyDNWHbYpKny4F+TvbyQ6XNVHrx1IAn5
+9UMPB3Q962/8hrRqK95Cs6AJ/D1Wdw9rwEqOC48waDzttYCVknn4L6rGECDdRM4
6pbWNTf3m9lzThWjiuEdNnPoNuKoBD9/UHWW/WRHjT6tbcGqstoyRKTsi8jjmwnC
9g4xWRsTdqYIAL4PBv32T+QYW/YcyRNTT97t/M0aukXxxxjCObehWVmBXVeNn0/9
lvvCgGgSJXtJHxzqcJ2I
=a2/6
-----END PGP SIGNATURE-----

 ③Bitcoin Coreのファイルのハッシュ値を確認

続いてSHA256によりハッシュ値を計算します。Windowsの場合は、コマンドプロンプトを開いて作業用のフォルダに移動した後「certUtil -hashfile bitcoin-0.12.1-win64.zip SHA256」などと入力します。

※Macの場合は「shasum -a 256 bitcoin-0.12.1-osx.dmg」、Linuxの場合は「sha256sum bitcoin-0.12.1-linux64.tar.gz」など。Windows含めてOSのバージョンによっては違うかもしれません。

すると、ハッシュ値が表示されるので②に書かれているハッシュ値と一致するかどうか確認します。一致していれば改ざんされていないと確認できます。

④署名が正しいことを確認する

簡易的な確認であれば、③までで十分ですが、②内のハッシュ値が改ざんされている可能性もゼロではありません。そこで②のファイルも正しいかどうか確認します。

④－１：検証のための準備

検証のためにGnuPGという公開鍵暗号方式の暗号化ソフトを利用します。各OSごとにバージョンが用意されているので好きなものをダウンロードしましょう。

https://www.gnupg.org/download/index.html

ダウンロードしたらインストールします。Windowsの場合、KleopatraというGUIソフトも同時にインストールされますが、基本的にはコマンドプロントからコマンドをうって利用することになります。

④－２：PGP公開鍵をダウンロード

②のファイルはBitcoin Coreの開発者の一人であるWladimir van der Laanにより署名されています。そこで彼のPGP公開鍵をダウンロードします。

https://bitcoin.org/laanwj-releases.asc

上のURLのようにBitcoin.orgにもアップロードされていますが、ハッキングされて改ざんされる可能性も考えて複数の場所からダウンロードして確認するのが理想です。

④－３：公開鍵をインポート

先ほどダウンロードした公開鍵をインポートします。コマンドプロンプト（ターミナル）を開いて作業用フォルダに移動した後「gpg --import laanwj-releases.asc」と入力するとインポートされます。

④－４：②の署名ファイルを検証

続いて②の署名ファイルが正しいか検証します。「gpg --verify SHA256SUMS.asc」と入力します。正しければ「Wladimir～（中略）～からの正しい署名」と表示されます。不正な場合は「不正な署名」と表示されるはずです。

ちなみにこの際、この鍵は信用できる署名で証明されていません！という警告が表示される場合がありますが、自分自身の鍵を作成していないために発生する警告文なので、ファイルの改ざんを確認するだけの用途であれば無視して構いません。

⑤複数人の署名を確認する

一応は④までで完了ですが、Bitcoin Coreは信頼性を高めるためにGitianという方法により複数人のグループによってビルドされています。そこで、先ほど使用したWladimir van der Laan以外の署名を確認することも可能です。

それぞれの署名は以下のgithubのページに保管されています。

https://github.com/bitcoin-core/gitian.sigs

各バージョン、OSごとに分かれており、特定のバージョンのフォルダを開くと署名した人ごとにフォルダが分類されているのが分かります。最下層には生のファイル（拡張子：assert）と署名ファイル（拡張子：sig）があるので、両方をダウンロードします。生のファイルは②と同様にBitcoin Coreのハッシュ値がかかれています。

署名をした人のPGP公開鍵を④－２のようにダウンロード、インポートして「gpg --verify bitcoin-win-signer-build.assert.sig bitcoin-win-signer-build.assert」と入力すれば検証が行われます。

PGP公開鍵は各自探してくださいとしか言えませんが、bitcoinのgithubのページにもまとめて保存されているので参考にしてみてください。

https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys

（４か月前に移動されたばかりで今後も場所が変わる可能性があるのでご注意を）

他のソフトについて

本記事では実際にウォレットとして使っている人はほとんどいないであろうBitcoin Coreの例を紹介しましたが、他のソフトでもふつう署名やハッシュ値も同時に公開されているので、同様の手順で改ざんされていないか検証を行うことができます。

例えばElectrumの場合も以下のダウンロードページに署名（signature）が添えられています。

https://electrum.org/#download

Electrumの場合は、Bitcoin Coreと違いハッシュ値が署名ファイルには表示されていませんが、「gpg --verify electrum-2.6.4.exe.asc electrum-2.6.4.exe」などと入力すれば署名と実行ファイルを検証することができます。

もちろん事前に署名者のPGP公開鍵もインポートしておいてください。Electrumは製作者のThomasVによって署名されており、Electrum関連の人の公開鍵はgithubにまとめられているので参考にしてください。

https://github.com/spesmilo/electrum/tree/master/pubkeys

The DAO事件から考えるパブリックなスマートコントラクトプラットフォームの未来

たまにはポエムを書きます。

パブリックな「スマートコントラクトプラットフォーム」の定義

スマートコントラクトの定義は曖昧で共通認識は定まっていませんが、本記事ではブロックチェーン上でユーザーが自由にプログラムコードを記述することができるプラットフォームのことを「スマートコントラクトプラットフォーム」と呼ぶことにします。具体的にはEthereum、Lisk、Expanse、Rise（時価総額順）などです。

The DAO事件から見えること

これらのプラットフォームは、どんなプログラムも動作させることのできる分散型コンピュータとして大きな利点ばかり以前は宣伝されてきましたが、The DAO事件から欠点も見えてきました。それは、①プログラムには必ずバグがつきまとう、②そのバグを容易に修正することができない、ということです。

①については、ある意味常識的な話でどんなプラットフォームを利用していようがプログラムを書く上でバグはつきものであり、どんな優秀なプログラマーであろうがバグを一つも出さないというのは不可能と言えます。従来のプログラムは例えバグが発生してもすぐ修正しても済む話なので大抵大きな問題にはなりませんが（時には大きな問題になることもありますが）、Ethereumの場合はそのバグをたとえ発見しても迅速に修正することが難しいので致命的になり得ます。

バグの修正能力をどこまで柔軟に持たせるか

そこで、このようなプラットフォームはどこまでバグに対して柔軟に対処させるか、ということが問題になります。Ethereum上で一度動かしたスマートコントラクトは永遠に止めることができないために事件は起きてしまいました。しかし、ではEthereum上のスマートコントラクトに全くバグに対する耐性がないかというとそういうわけではありません。Ethereum上のプログラム（スマートコントラクト）は他のプログラムからのトランザクションを受けて実行させることができるので、例えばバグを修正した新たなプログラムを作成し、元のプログラムから新しいプログラムに内部の保存データを移し「バージョンアップ」することも可能です。The DAOの場合は修正のために内部トークンの保有者の投票による賛成が必要であり「バージョンアップ」のハードルが非常に高かったので、迅速に対応することができず、バグが修正されることなく終了ということになってしまいました。

今回は正確にはバグ修正というかたちではありませんでしたが、ハードフォークもバグ修正の方法の一つといえるでしょう。

事件から感じたのは、バグを修正する「権力者」をスマートコントラクトに対して置くことが現段階ではまだまだ必要であるということです。

※超単純なプログラムであったり、十分な期間十分な人間によって安全だと確認されたプログラムはこの限りでありません。

完全な「信用が不必要」（trustless）は不可能

バグを修正する権力者を置くことは、当然その権力者がプログラムを悪意を持って改変する可能性があるということなので、プログラムを利用する上では権力者を信用しなければなりません。これは、信用が不必要（trustless）というEthereumなどの分散型プラットフォームの理念と真っ向から対立するものとも言えます。

しかし、コードを簡単に修正できないようにすれば「信用」が必要なくなるわけではありません。多くの人はプログラムコードを読むことができないので、プログラムを書いた人間、あるいはそのプログラムを監査してバグがないと発信する人間を信用せざるを得ません。仮にどんな言語で書かれたプログラムも完璧に読める天才であったとしても、いちいち自分が利用するプログラムのソースコードをすべて読み込むのは非現実的です。

そして、trustlessだったはずのコードに裏切られるかたちで事件が起きてしまいました。いろいろな意見があると思いますが、個人的にはThe DAOのコードを書いた開発者が無能だとかコードをチェックした開発者が無能であるとは思いません。プログラムにバグは必ずつきものなのです。

Ethereumのハードフォークには違和感

当初は特に書きませんでしたが、私自身はEthereumのソフトフォークにもハードフォークにも反対でした。なぜなら、Ethereum本体のバグではなくThe DAOのコードのバグであったことと、The DAO（+Ethereum）はそもそもこのようなバグに対して最初から迅速・柔軟に修正できる能力を放棄することによって「trustless」の理念を宣伝していたと思っていたからです。当初掲げていた理念と真逆のことを宣言されては違和感を感じてしまいます。唯一納得でき得る根拠は、ETHが盗難されることで将来Proof of Stakeに移行する際の懸念となるというものでしたが、この点もメインの根拠として議論されていたわけではなくまたPoS実装自体はまだまだ先でいくらでも対応のしようがあると思うので、それでも不十分であると感じていました。

ちなみにEthereum Classicにも反対です。フォーク前だったら支持したでしょうが、マイナーがフォークを支持した後の今となっては、ETCはReplay Attackなどの混乱を生むだけですし、開発を行う上でも余計複雑になって結果的にEthereum全体のマイナスとなると思うからです。

「ロールバック」を是とするならEthereumよりLisk

結果的にEthereumのコミュニティはハードフォークを支持して、コード上で書くことによって強制的に引き出されたETHを移動させて実質的な「ロールバック」を行うことになりました。

しかし、もし「ロールバック」を良しとするのであれば、Ethereumはベストの選択肢ではないと思います。なぜなら、Ethereum本体とは直接関係ないはずの一ユーザーが書いただけの一つのコントラクトコードの脆弱性のせいでEthereumの全利用者を巻き込まなければならないからです。

Liskのようにプログラムごとに独自のブロックチェーンを立ち上げるサイドチェーンを利用していれば、本体のブロックチェーンへの影響は最小限にそのサイドチェーンやプログラムの利用者の範囲内だけでロールバックが可能です。サイドチェーンであればコンセンサスアルゴリズムを自由に選ぶこともできるので、プログラムの修正もより柔軟に行うことが可能で、迅速な修正・対応を目的とするのであればEthereumよりもLiskが優れていると言えます。

※コンセプトだけを見ればLiskは優れていると感じていますが、個人的には開発チームの開発力に対する懸念やスマートコントラクト(DApps)の開発コミュニティがEthereumに比べて非常に小さいことなどから、必ずしもLisk自体が成功できるとは思っていません。

Ethereumの理想は遠い？

プログラムからバグを完全になくすことは不可能ですが、十分に単純であったりかなり長い期間、多くの人による検証が行われればある程度までバグの混入確率を減らすことは可能です。十分長い期間を掛ければ当初Ethereumが提唱していた改ざん・検閲不可能で止めることができないスマートコントラクトを安全に実行することもできるかもしれません。

しかし、利用者からみればコード開発者やそのコードを信用するのが完全に不要になることは永遠にありません。0か100かという話ではなく、どこにどの程度信用を置くのかということになってくるのでしょう。

半減期後にビットコインの価格が下落してマイナーの採算が取れなくなったらどうなる？

先日、香港の大手取引所Bitfinexのハッキング事件によってビットコインの価格が大きく下落しました。この件はこの件でいろいろと興味深いものの、情報が錯綜している部分もあるのでしばらく様子を見たいと思います。

今回は、収入が25BTC/ブロックから12.5BTC/ブロックに半減してしまったのにも関わらず価格が下がっている現状に関して、ビットコインの基本的な仕組みにはなりますが、マイナーの採算が取れなくなったらビットコインはどうなるか？について書いてみます。

長期的な視点

マイナーの採算が取れなくなったら、一部マイナーは採掘を止めてしまうことが考えられます。そのため、一時的にビットコインの採掘速度（ハッシュレート）が低下し、ブロックの生成間隔（取引の承認時間）が長くなってしまうことが考えられます。しかし、ビットコインにはdifficulty（採掘難易度）の調整が2016ブロックに1回（約2週間に1回）行われるので、ちょうど生成間隔が10分になるように調整された後はこれまでと同じように何の問題なくビットコインが続いていきます。

ビットコインの価格について書かれたサイトでは、マイナーの損益分岐点の話をしている記事をしばしば目にしますが、当然のことながら損益分岐点は変動します。

今回の場合、マイナーが減少⇒difficultyが減少⇒ハッシュレート（採掘力）あたりのブロック生成確率が上昇、という流れになりマイナーの損益分岐価格は下がることになるわけです。

例えば半減期前の損益分岐価格は40,000円/BTCだったとします。その他の条件が全て変わらないとすれば、半減期後は収入が半分になるので損益分岐価格は80,000円/BTCとなります。よってビットコイン価格が8万円以上にならないとマイナーの採算は取れなくなってしまいますが、マイナーが採掘を取りやめてdifficultyが減少すれば、採掘を続けているマイナーの利益率は上がっていくため、それに伴い損益分岐価格も80,000円/BTCから下がっていくことになるのです。

このようにビットコインにはハッシュレートの下落に対応できる仕組みを備えており、マイニングプールの集中化や一時的な取引承認時間（ブロック生成間隔）の増加などの懸念がないわけではないですが、成長し続けなければ破綻するというポンジスキーム的なものにはなっていません。

短期的な視点

問題とされるのが短期的な影響です。問題の最大の原因は、2016ブロックに1回、約2週間に1回「しか」difficultyの調整が行われないことにあります。この点は早くから問題にされ、今ではほとんどのアルトコインで1ブロック毎にdifficultyの調整が行われるよう設定されています。

実際に約半年前にビットコインの開発チームのメーリングリストで、difficultyの調整アルゴリズムをハードフォークによって修正するコードを用意すべきではないか、ということが議論になったこともありました。

メーリングリストの中で、もし価格が下落することによってハッシュレートが50%下落した場合、それによってブロックの生成間隔は20分となり、1ブロックあたりに含まれる取引量も2倍になるという仮定が挙げられています。現在のブロックサイズの上限は1MBであり、最近はその上限に近づいているので、仮にハッシュレートが半減しようものなら、ブロックサイズの上限から溢れて多くの取引がブロックに取り込まれない状況が続き、順番待ちの取引が無限に増えていくことになるわけです。ビットコインを送信しても全然承認されない、というのは大問題となります。このような状況となり、多くの人がビットコインはもうおしまいと思ってさらに価格が下落すれば、マイナーの採算が取れなくなってさらにどんどんハッシュレートも下がってしまう悪循環に陥ってしまうのです。

difficultyさえ調整されれば問題はありませんが、調整は2016ブロックに1回しか行われません。通常通り10分間隔でブロックが採掘されれば約2週間です。しかし、20分間隔になれば約4週間、最悪の場合は半永久的にdifficultyの調整がされないなんて可能性もあります。

万が一こんな状況になれば、ビットコインをハードフォークしてdifficultyを手動で設定するしかありません。

現実は？

先のメーリングリストでは議題に上ったものの、そもそもハッシュレートが急激に50%も下落するということは非現実的であると考えられ、実際には真剣に検討されることはありませんでした。（他にもハードフォークのリスクや新しい調整アルゴリズムの導入による脆弱性のリスクが大きすぎるため）

bitcoinwisdomによれば、半減期後のハッシュレートは下落傾向にありましたが、普段から観測されるような誤差範囲程度の下落にしかすぎず、しかも現在は回復傾向にあります。

ハッシュレートが急激に下がることが非現実的である理由はいくつか考えられています。なかでも一番大きい根拠と考えられるのが、そもそもビットコインの採掘の経費は、マイニング設備への初期投資費用が多くを占め、継続してかかる（中国での）電気代は非常に少ないのではないか、ということです。中国のマイニング業者は、電気を一定量（例えば一年間分）ごと購入して支払っており、電気は貯めておくのが難しいので少なくとも購入した分は採掘し続けるだろうという話もあります。

実際の数値はよくわかりませんが、初期投資費用を無視してビットコインの採掘報酬（12.5BTC/ブロック）と電気代だけから考えれば、かなり高い利益率を上げられる、つまり損益分岐価格はかなり低いのではないかと考えられます。

いずれにしても、今回の半減期によるハッシュレートの低下は大方の予想通り限定的なものとなりました。2012年の1回目の半減期、2014年初めの中国での規制/Mt.Gox事件よるビットコイン大暴落、その他アルトコインの事例を見渡してみても、価格下落によるビットコインネットワークへの影響というのは小さいものと思われます。

Ethereum ClassicのReplay Attackとは何か？

先日コミュニティの多くの支持を受けてイーサリアムがハードフォークしました。一部がEthereum Classicとしてハードフォークに反対するバージョンを立ち上げブロックチェーンは分岐状態となっていますが、フォーク前には著名な賛同者がいなかったのでほどなく消えるものと思われました。しかし、ここにきて大手取引所のPoloniexがETC(Ethereum Classic, ETHC)のトレードを開始し、大手マイニングプールのF2Poolもマイニングを開始するというニュースが流れ少なくとも今すぐ消えるという状況ではなくなってしまいました。

ETCが無価値＝0円になれば何の問題もありませんが、ETCに1円でも価値がある限り、特に取引所においてReplay Attackという危険性があります。

前提

ハードフォークは日本時間の7/20 22:30頃、1920000番目のブロックで行われました。このタイミングでイーサリアムのブロックチェーンはハードフォークを行うETHと行わないETCの二つに分岐しています。つまり、ハードフォーク直前にETHの残高があるアドレスに、誰でも等量のETHとETCを保有していることになります。

ETHとETCは全く同じアドレス・秘密鍵の構造やネットワークを利用しているので、「アドレスAからアドレスBへ10ETHを送信する」というトランザクションを送信すると、Ethereum Classicのノードもこれを受け取って同時に「アドレスAからアドレスBへ10ETCを送信する」トランザクションが送信されることになってしまいます。逆にEthereum Classic上で同じことを行っても同様の現象が発生します。

ただし、ハードフォークが行われたDAO関連のETHは全てEthereum Classicでは無効と見なされるのでETHのブロックチェーン上でしか移動が行われません。先日記事に書いたDAOと交換されたETHはEthereum Classic上のブロックチェーンでは存在し得ない（秘密鍵を所持していない）ことになります。

Replay Attackとは

ハードフォーク直前にあるETH残高はそのままETC残高に反映されるので、取引所のホットウォレット/コールドウォレットにETHがあるということは、同じ量のETCがあることになります。

何の対策もしていない取引所でハードフォーク後にETHの出金処理を実行した場合、同時にETCも引き出されることになります。ETCがただのゴミならいいのですが、現在は価値がついてしまっているのでこれが問題となります。

ETHとETCを個人のウォレットBに引き出してから、ETCだけ別のアドレスCに移しETHを再び取引所のウォレットAに預けた後、もう一回ETHの出金処理を実行すると再度ETCもウォレットBに一緒に引き出せてしまうのです。取引所のウォレットのETC残高が尽きるまで、ウォレットB(ETH)→A(ETH/ETC)→B(ETH/ETC)→C(ETC)へ移していく作業を繰り返せば一定のETHがあるだけで多額のETCを入手することができてしまいます。これがReplay Attackと呼ばれています。

この問題は秘密鍵がなくても自動的にプログラムにより送信処理が行われる取引所のウォレットなどに顕著なもので、ETHまたはETCのどちらかのアドレスの秘密鍵がわからない限り、基本的にReplay Attackはできないので1ユーザーのウォレットへのReplay Attackは心配する必要はありません。

日本の取引所は良く知りませんが（対策されていることを望みますが）、海外の大手Poloniex/Bitfinex/Krakenなどは対策されているようです。

追記：一般的にはETHとETCを同時に送信させること自体を「Replay Attack」と呼びますが、ここでは現実的な「攻撃」の例として取引所への攻撃を挙げています。

ユーザーが気を付けることは？

Ethereum Classicなんてどうでもいい、売って金になるとしてもどうでもいい、という人はいいのですが、そうでない人はハードフォーク後のETHの送信に気を付けなくてはなりません。ETHを送信する裏でETCも同時に送信することになるので、下手に取引所などに送ってしまうとETCが消失する可能性があります。

ETCを売りたいとき、現在のところ唯一対応しているのがPoloniexです。Poloniexの場合、ETHを送信すると同時にETCの残高にも反映してくれます。ただし、たまにETC側のノードが拾ってくれず、送信が遅れたり送信されなかったりすることもあるようなので、慎重に自己責任で行ってください。送信元のアドレスにETCがないともちろんPoloniex側のETCの残高には反映されないので、Ethereum ClassicのブロックエクスプローラーなどでETC残高を確認しておきましょう。

Ethereum Classic Block Explorer

※アドレスは小文字のみで入力しないと正しく表示されないようです。

ユーザーが取引所においてあるETHについて

Poloniexではユーザーが保有しているETH残高と同量のETCを付与することにしたようですが、他の取引所については各取引所側の判断となります。取引所がETCは取引所側の持ち分にすると決めてしまえば、ユーザーがETCを受け取ることは当然できません。ハードフォーク前に取引所にETHを持っていたとしても、そのままETCを持っていることにはならないので注意しましょう。

Ethereum Classicのウォレット

今の時点でEthereum Classicに標準対応しているウォレットはありません。Mistで別の名前のブロックチェーン保存用フォルダを作って、フォークを支持しないオプションを選んでからブロックチェーンをダウンロードすれば、ETHとETCを同時かつ分別して保管することも可能ですが、よくわからない人は触らないほうがいいでしょう。

Ethereum Classicが生き延びるとすればいずれウォレットが対応するはずなので、今の時点は何もしないか対応している取引所上に保管しておくのが無難だと思います。

ETHとETCを分けて送信する方法は？

ノードもウォレットも対応していないので、ETHとETCを分けて送信するにはスマートコントラクトを利用するしかありません。これもよくわからない人は、対応するまでは同時に送信されてしまう仕様だと思って触らないのが無難だと思います。

両方扱いたい場合、不便は不便なのでローカルのETC専用のアドレスを作ってからPoloniexに一度預けてから再度引き出して分別保管するのが安全かもしれません。（ただし上手くETCが送信できるかどうかはわからないので自己責任で。）

いくつかスマートコントラクトのコードが提案されているのでリンクだけ貼っておきます。

How to deal with the Ethereum Replay Attack — Medium

go ethereum - How to conditionally send ethers to another account post-hard-fork to protect yourself from replay attacks - Ethereum Stack Exchange

ttps://www.reddit.com/r/EthereumClassic/comments/4ucxdu/etc_and_eth_keep_them_separated/