Bitcoinとイスラム教
Bitcoinに関して、エジプトのイスラム指導者が「ハラム（イスラム法に反している）」というファトワ（法学者の意見）を表明しました。
Saudi Cleric Says Digital Currency Bitcoin is Haram in Islam
私自身はムスリムでもなんでもないですが、ムスリムが多い国にしばらく滞在しているので、今後の規制を考える参考として一度現状をまとめてみました。
そもそもイスラム教って
前提として理解しておきたい、イスラム教知識をまとめます。
なお、調べながら書いているので、「それは違う！」ということがありましたらご指摘いただけると嬉しいです。
イスラム世界での法解釈手段
ご存知の通り、イスラム教は現在のサラジアラビアでムハンマドによって誕生しました。誕生後、誰が正当なイスラム教の指導者かを巡って、大きくスンナ派とシーア派に分裂します。シーア派はその時々の指導者による指導を重視する一方で、スンナ派は聖典であるクルアーン（コーラン）やハディースというムハンマドの言行をまとめたドキュメントを重視しています。
さて、上述の通りスンナ派ではクルアーンやハディースなどのドキュメントがあるわけですが、当然時代の移り変わりに伴ってそれだけでは直接適用できない問題が発生します。Bitcoinもそうですし、Facebookなどのソーシャルメディアもイスラム教としてOKかどうかが気になって手を出せない人も出てきてしまいます。
そうした問題が出たときの解決方法として、スンナ派が考えているのがイスラム法学者による「合意」と「類推」です。
ファトワ
Bitcoinがイスラム法に則って、合法（ハラル）かどうかを気にするムスリムは、法学者に対してBitcoinは合法かどうかのお伺いを立てることができます。その要請に基づいて、イスラム法学者はクルアーンやハディースからイスラム教が意図する方向性を考え、その考えに基づいて自身の見解を示します。
これらの見解がイスラム法学者間で反論もなく一致したら、「合意」が形成されたとみなされます。ただ、当然解釈には複数の解釈が考えられる問題もあり、イスラム法学者間でその意見が割れることはよくあります （ちなみに、以前には雪だるまやミッキーマウスが偶像として違法認定されたことも。。。）。
そういった場合には、各イスラム法学者によって見解は割れるものの、クルアーンやハディースからの「類推」で、合法かどうかを判断することになります。ただ、それだと見解が割れてしまい困ったことになるので、国によっては、統一的な見解を出すために評議会のような合議制の決定機関を持つ国もあります。例えばインドネシアでは、インドネシアウラマー評議会（MUI）という機関が法解釈を統一しています。
そして、これらの「合意」や「類推」の元になる各イスラム法学者の公式見解を「ファトワ」と呼んでいます。
参考
イスラム法の法源について
http://d.hatena.ne.jp/coffee_tambe/20131119
イスラム教の全体的な歴史は、以下の広瀬さんの記事が分かりやすいです。
１５分でわかるイスラム教 - Market Hack
Bitcoinのイスラム教における位置づけ
Bitcoinは21世紀に誕生したものなので、当然クルアーンやハディースに情報はありません。そのため、各イスラム法学者が見解を出して、その見解に基づいてだんだんと統一見解が生まれていくという流れになります。
去年cointetelegraphに掲載された記事では、あるインドネシア起業家のコメントとして、Bitcoinはハラル（合法）なのではないかという見解を載せています。ただし、彼は（おそらく）イスラム法学者ではないので、イスラム世界における法解釈には影響がありません。これは当たり前のことで、日本でも誰もが独自に自分の解釈が法律だと言いだしたら、わけのわからないことになってしまいます。
https://cointelegraph.com/news/is-bitcoin-halal-how-cryptocurrency-conforms-with-islam-and-sharia
このように統一見解がない中で、「ビットコインはハラム（違法）だ」と述べたイスラム法学者が現れたというのが先日の記事です。その根拠は、大きく2つあり、
- Bitcoinの持つ匿名性（anonymousity）がドラッグ購入などの違法な用途に使われるため
- 価格推移が投機的
というものです。また、11月にもトルコの宗教関連団体が「Cryptocurrencyは違法である」という見解を表明していますし（理由はほぼ同じで、違法な用途に使われることが多いとのこと）、サウジアラビアの皇太子もエンロン事件とスキームが同じだということを話しています。
もちろんこの「匿名性」というのは、技術的には誤解でありそれが理由だとすると、あまり説得力を持たないものと考えられるかもしれません。ただ、投機的という点については否定することは難しく、それを根拠にイスラム世界で非合法ということになるかもしれません。
A Saudi cleric says 'bitcoin' is haram ... wait, what?
ただ、今回の件で覚えておきたいことは、この解釈はまだイスラム教世界で確定したものではなく、この指導者を指導者と考えるコミュニティ内でしか効力がないという点です。同じイスラムといっても、サウジアラビアなどのイスラム教が国家単位で適用される国から、インドネシアのように土着の宗教と一体化しており、イスラム法はあくまでも法ではなく、社会規範として存在しているような国もあるので、一人の指導者の見解があまねく全体に適用されるというわけではないのです。
今回のファトワが今後のイスラム世界でのBitcoinの解釈に影響を及ぼすことはあるでしょうが、その解釈が固まるのはまだまだ先でしょう（というより、永遠に固まらないかもしれないですが）。
ちなみにイスラム世界では「ハワラ」という匿名送金手段もあり、こちらはハラル（合法）となっているようです。そことの整合性を考えると、匿名性とかブラックマーケットでの利用というのはあまり理由にならない気もします。
www.cryptocoiner.info
番外編
Kojiさんが最新動向を調査するとのことなので、楽しみにしています！
やっぱりガチの中東とかに行った方が参考になりそうですが、そもそもの認知とかが低くて業界とかはあんまりなさそうなんですよね～。今年一回どこかでイスラム圏行ってみたくなりました。トルコとかかな（観光する気満々笑）
— Koji Higashi (@Coin_and_Peace) 2018年1月7日
Bitcoinブロック拡大論争 両陣営の意見
平野さんが「週末の読み物」と題してBitcoinブロック論争のまとめ記事を、Twitterでシェアしていました。いずれの記事も両陣営の意見をよく反映している良記事でしたので、それぞれの意見をここで簡単にまとめておきたいと思います。
週末の読み物のご案内です。それぞれ逆サイドから。
— Junya Hirano 平野淳也 (@junbhirano) 2017年10月21日
非中央集権化の目的。なぜビットコインは小さいブロックサイズのほうが良いのか？→ https://t.co/UtdvS41qFP
ビットコインキャッシュこそが、本物のビットコイン→ https://t.co/GDJwbsTzC5
対立軸
Bitcoinなどの暗号通貨に一般的に求められるがトレードオフとなる要件として、セキュリティと利便性の2点がよく取り上げられると思います。
このうち、外部からの干渉への耐性などのセキュリティを重視する立場にあるのがコア開発者が主導するSmall Block派です。それに対して、取引手数料の安さ、取引確定の時間など利便性を追求する立場が、Bitcoin Cashに代表されるBig Block派であるといえます。
実際には、裏側にはマイナーやビジネスサイドの権力闘争なども噂されますが、どこまでが真実か定かではないのでここでは触れません。
Small Block派の意見
Small Block派はBitcoinの存在価値はDecentralizeであることだと考えており、政府など外部からの干渉によりBitcoinネットワークが崩壊することを危惧する立場です。彼らがBig Blockに対して反対する根拠は、Big BlockがDecentralizeとはかけ離れた思想であるためです。
そのポイントは2点あり、
- Miner、Full Nodeの寡占
- マイニングの匿名性の低下
を警戒しています。
元記事はこちら
bitcoinmagazine.com
Miner、Full Nodeの寡占
ブロックサイズが拡大すると、マイナーがブロックを発見した後で、ブロックをPropage (ネットワーク内に伝播)する時間に遅延が発生します。この遅延が発生することを利用して、ブロックを発見したマイナーは他のマイナーに先駆けてマイニングをスタートすることが可能になります。
このことが何を産むかというと、ハッシュパワーに比例したマイニング機会の平等が崩れ、ハッシュパワーを多く蓄積している大規模マイナーがハッシュパワー比で見て有利になる状況です。このような状況に陥ると、小規模マイナーが次第に大規模マイナー（マイニグプール）に集約されていき、マイニングの寡占化が発生します。
これに加えて、最近ではマイナー間で一種の共謀が行われていることが判明しています。ブロック全体を伝播すると、伝播時間が遅くなりがちですが、共謀したマイナー間でブロック全体ではなく、ブロックへダーのみを事前に伝播しあうことで、共謀したマイナー間では他のマイナーよりも有利にマイニングを行うことが可能になります。
ハッシュパワー比でのマイニング機会の平等が崩れているのに加えて、マイナー間共謀でさらに平等性が崩れるイメージ
マイナーの寡占は次の項で説明するマイナーの匿名性の低下と相まって、政府など外部からの規制に対する脆弱性が上昇する結果につながります。
さらに、ブロックサイズが拡大すると、フルノードを運営する人々も負担が増えることにつながります。結果として、フルノード数が減少すると、マイナーが作成したブロックを検証するのに、少数のフルノードをトラストすることが必要になり、こちらについても外部規制への脆弱性が上昇することにつながってしまいます。
マイナーの匿名性の低下
マイナーの寡占化の項で見た通り、Big BlockはPropagation時間に影響を与えます。
マイニングを実施する際に匿名性を維持しようと考えるとTorなどの匿名化ソフトを利用することが考えられますが、Torを利用するとPropagationされたブロックを収集するのにも時間がかかってしまいます。Big Blockを利用するとこの時間は当然増大します。
結果として、匿名化マイナーの維持が困難になると、これまた外部からの規制に対する脆弱性が上昇することにつながります。
Big Block派の意見
これに対してBig Block派はBitcoinの存在価値を、外部からの干渉への耐性ではなく、取引手数料の安さ、取引確定の時間など利便性に置いており、思想が全く異なるものだといえます。
元記事はこちら
www.bitcoin.com
2016年頃までのBitcoinは現在とは異なり送金手数料がほとんどかからず、なおかつトランザクションは通常1ブロック以内にブロックに取り込まれて、取引が確定されていました。しかし、Bitcoin利用者が増加することに伴いスケーリング問題が発生し、Bitcoinの送金を素早く行いたいと考えると、現在では高額の手数料を支払う必要があります。
Bitcoin Cashは2016年頃までのBitcoinのお手軽さ、便利さを取り戻そうという思想です。上記元記事に、わかりやすい比較画像があったので、引用します。
Small Block派の反論
利便性が低下することに対して、Small Block派もただ黙っているわけではありません。彼らのアイデアは、Bitcoin送金ネットワーク自体は、Small Blockでセキュリティを保証する。それに加えて、別レイヤーで簡便な送金手段を提供するというものです。
別レイヤーというと、最近ではSegWit導入で現実味を帯びてきたLightning Networkもありますが、ビットコインをチャージできるデビットカードなどもここに含まれます。つまり、基本的にはオンチェーンで取引を完結させることでセキュリティを確保する一方、少額決済に利用したい場合はLightning Networkを利用したオフチェーンを利用したり、トラストレスが求められない局面ではデビットカードを利用してFiatに変えることで利便性を担保しようというアイデアです。
Lightningのネットワークの要素技術であるマイクロペイメントチャネルの紹介
cryptocoin.hatenablog.com
まとめ
Big Block派の権化みたいなシンガポール観光記事を書いておいてなんですが、個人的にはBitcoinの価値は、外部からの干渉を受けない堅牢性にあると思っているので、Small Block派です。早く、安く送金したいなら、銀行、PaypalやLINE Payなどを使えばいいんじゃないかな、と。
cryptocoin.hatenablog.com
いずれにしても、11月にSegWit 2XへのフォークをBitcoinは控えており、Bitcoin、Bitcoin Cash、Bitcoin 2Xがどのような変遷をたどっていくかは気になるところです。11月以降も、少し油断すると浦島太郎状態になる状況は続きそうですね。
インドネシア新都市計画 Meikarta Project
今回は暗号通貨から離れて、インドネシアの首都、ジャカルタ近郊で進行中の都市開発プロジェクト Meikarta Projectの紹介をしたいと思います。都市開発というと、最近の日本では東京・丸の内エリアの再開発などが進んでいますが、このプロジェクトは今まで更地だった土地に新たな街を産み出そうとしている点でスケールが違います。
インドネシアの良くも悪くもある所ですが、ぱっとした見た目に左右されることが多く、このMeikarta紹介動画もインドネシアなのにヨーロッパの木々が植えられていたり、白人の男女がランニングしていたりと、実際の生活というよりは、理想像に近いイメージ重視という印象です。
なんだろう、この近未来感笑
Meikarta Projectの規模
ジャカルタは現在人口1000万人を抱え、人口密度も世界第9位になるなど、そのキャパシティが限界に達しようとしています。そこで現在ジャカルタとその周辺部であるブカシなどをつなぐ鉄道建設を進めており、それに伴う郊外の開発を進めています。今回のMeikarta Projectはその一環ではありますが、ただのマンション建設ではなく、公園、学校、ホテル、鉄道、空港、港などを含めた街全体を作り出そうという所に大きな特徴があります。
試しに最近の日本における都市開発と規模を比較してみると、
品川再開発：5000億円 （品川周辺 5000億円再開発 ＪＲ東など、超高層ビル８棟 ：日本経済新聞）
丸の内・常盤橋再開発: 1兆円（三菱地所、「丸の内」死守 東京駅前に高さ日本一ビル発表 ：日本経済新聞）
Meikarta Project: 2.3兆円 (278兆ルピア)（Lippo Group to Develop $21B Meikarta Industrial City | Globe Asia)
と、丸の内常盤橋再開発の2倍以上の規模となっています。当然建設にかかる人件費はインドネシアの方が格安ですから、実際にはそれ以上の規模の差があると言えます。
開発はインドネシアの有力中華系財閥であるLippoグループが手がけています。Lippoグループはジャカルタ市内に複数のモール、ホテルを所有する不動産系の財閥 (それ以外にも、病院やコーヒーチェン (Maxx Coffee)などを所有)ですが、その財閥をもってしても今回の開発は過去最大規模となるようです。日本からも三菱 (おそらく自動車)、トヨタなど複数の企業が参加しています。
ロケーション
場所はジャカルタの南東、約45キロの地点です。このあたりは同じくLippoグループが開発してきたチカランと呼ばれるエリアにほど近く、日本、韓国などの自動車系の工場が多く立ち並んでおり、すでに工業都市としてはある程度成熟した街になっています。
ただ、この街、主なアクセス手段は車になるますが、ここはインドネシア。毎朝、毎晩悲惨な渋滞が発生します。ジャカルタから45キロしかないにも関わらず、時には4時間くらいかかる始末。
しかし、その点はLippoグループも考えているようで、
- ジャカルタとバンドンをつなぐ高速鉄道（中国企業が建設中）の中継駅
- MRTの建設
- 新高速道路の建設 (Kartajati Airport、Meikartaから70キロくらい離れていると思いますが笑)
- 新国際空港の建設
などを通して、ジャカルタ、その他の地域へのアクセスはかなり改善しそうです。
宣伝
宣伝はかなり煽っていて、ニューヨークのCentral Parkを摸した公園や、中国のシリコンバレーと呼ばれる深圳をモデルにした都市にすると大々的に宣伝しています。また、Youtubeを見ているとこんな動画も (インドネシア語ですが雰囲気で分かるかと)。
MEIKARTA - Aku ingin pindah ke Meikarta - Tvc 60"
ジャカルタ、どんだけ危ない街なんだよ笑
もらったパンフレットによると、部屋の広さは最小21.91平米の単身用から、最大でも83.62平米の家族用と比較的小ぶりなサイズな模様。また、宣伝を大々的にしているモールも、超高級モールというよりはそこからひとつランクが下がったレベルのモールであることを考えると、ターゲットは中所得者層向け（月給12万円程度）であると推察されます。
それも当然で、第1期で25万戸 (家族4人だとすると、100万人！)を作成する予定の大規模プロジェクトであるため、高所得者だけ狙ったとするとパイが足りません。Lippo曰く、1日あたり3000件から5000件売るのをターゲットとして販売戦略を立てていることからも、その規模感がわかるかと思います。日本だと、東急電鉄が田園都市を開発したのと近いイメージではないでしょうか？
今後
モデルにしている深圳の歴史をたどってみると、元はただの集落に過ぎなかった街が、香港との地理的な近さから政策的に開発されてきて、現在中国第4の都市にまで成長しました。
Meikartaも同様に現在はただの更地ですが、インフラ開発を並行して行うことで、今後インドネシア第２の街として発展する大きなポテンシャルを秘めているかと思います。さらに、ジャカルタの場合は既存のインフラを順次破壊して再構築する必要があるのに対して、何もないMeikartaの場合は一から自由に設計できるという大きなアドバンテージがあります。
インドネシアではプロジェクトが遅延することは多々あることなので油断は禁物ですが、大きなポテンシャルを秘めていることは間違いないでしょう。
VALUとZaifトークンは無価値である
8月27日 (日)、Zaifトークンが突如2.5円まで急騰したかと思いきや、そのまま0.4円台まで急落し、一部のトークン保有者が「補償しろ」、「ロールバックしろ」というコメントをZaifに向けて浴びせる阿鼻叫喚な光景が広がっています。
（現在は1円付近まで回復した模様）
もともとは、「Zaifを運営するテックビューロがICOを発表したCOMSA」と「Zaifトークン」が連携することへの期待という、投資するには非常に弱い根拠を元に、Zaifトークンは買い上げられていました (＋イケハヤ、Zaifチャットなどの煽り)。そのような状況で、Zaif側から「COMSAとの連携予定はない」との発表があり、根拠としていた前提が崩れて価格が急落したという状況です。
この一連の流れについて、市場操作だと言ってZaifを責める声もありますが、トークンで損した人はただの噂をベースに買い上げて損しただけであり、自己責任であると言えるでしょう。
さて、そもそもこのZaifトークンですが、このトークン自体に今現在裏付けとなる価値は何一つありません。最近話題のVALUについても当てはまりますが、このトークンを買ったからといって何か特別な権利を得られるわけではなく、ただのトークンというデジタルアセットを手に入れたにすぎません。株式やBitcoinと比較することで、この点はさらに明確になるかと思います。
目次
株式との比較
株式の場合は企業が生み出した利益剰余金から、「配当」を受け取る権利が会社法で保証されています。もちろん、株主総会決議で利益剰余金を配当に回さないという決定を下すことはできますが、あくまでも最終的に配当を決めるのは株主です (取締役会設置会社の場合は取締役会の決議事項ですが、取締役の選任は最終的には株主が決定しているため、株主の意向に逆らって配当を拒否することは完全にはできません)。
一方、VALUやZaifトークンには、VALU発行者やテックビューロの生み出した利益から配当を受け取る権利は当然ありません。
また、株価は理論的には将来の配当を現在価値に割り戻したものとされています。このように株式には価格が生まれる根拠がありますが、VALUやZaifトークンの場合は将来的に何かしらのお金をもらえることが一切保証されていないため、価格が0円以上になる根拠がありません (VALUの場合、トークン発行者が何かしらの「優待」を提示する場合もあるので、その分は価格として織り込まれる余地はあります)。
さらに、株式のもう一つの機能として、会社の方針に口を出す権利が会社法で認められています。これは、株主総会での議決権であったり、株主総会での議題の提出権であったり様々ですが、いずれも会社法で法律として認められています。当然ですが、ValuやZaifトークンにはこのように会社の経営に口を出す権利は一切認められていません。
ここで、会計上トークンをどのように位置付けられるか考えてみましょう。ValuやZaifトークンの配布時の仕訳は、以下のようになるかと思います。
トークン配布時
現金 (資産) 100 / トークン発行益 (収益) 100
一方、株式の新規発行を考えると、以下の仕訳になります。
新規株式発行時
現金 (資産) 100 / 資本金 (資本) 100
一見同じように見えますがそこには大きな違いがあり、トークン発行益は損益計算書上の売上である一方、株式の場合は貸借対照表上の資本の増加になります。会社から見ると、株式の場合はこれから実施する事業のための資金調達の手段として株式を発行したということになりますが、トークンの場合は稼ぐための一手段でしかないということになります。
上の図でわかるように、この稼ぎは最終的に純利益となって、貸借対照表上の利益剰余金に計上され株主への配当原資となります。つまるところ、トークン発行はトークン保有者を利するものではなく、株主を利するためのものに過ぎません。もちろん、このトークンがその価格に見合ったサービスを提供してくれるのであれば意味のあるものですが、一切の見返りがない以上、トークンとしての価値はゼロであると言えるでしょう。
Bitcoinとの比較
Bitcoinの根元価値が何かという点は議論が絶えませんが、一つの特徴として中央管理者が不在で、分散型で運営されているということがあげられるかと思います。分散型という仕組みにより、特定の人・団体が恣意的にBitcoinの仕組みをゆがめたり、不正を働くことができづらい仕組みになっています。
この点は現在の法定通貨 (Fiat)とは大きく異なる点であり、既存の政府の貨幣政策を信用できない人からすると、資金の退避先として都合がよい仕組みになっています。
一方、Valuやトークンの場合は、特定の発行主体が存在します。Zaifトークンの場合はZaifですし、VALUの場合はイケハヤや最近炎上したYouTuberのヒカルであったりするわけです。法定通貨の場合は貨幣供給量を自由にコントロールできるため、インフレにより貨幣価値が希薄化されることが多々あります。特定の発行体が存在するということは、法定通貨と同様の価格操作が簡単にできてしまうということを意味します。
まとめ
以上のように、VALU、Zaifトークンともに株式のように配当や経営権を約束されたものではなく、またBitcoinのような分散型の仕組みでもないことが分かるかと思います。
今回の騒動は、何かしらの商品を買うときは、その裏にある本当の価値とは何かを意識しないと、自らの資産を溶かすことになるいい教訓かと思います。また、このようなトークンがここまで買い上げられたのは、これまでの限られた人だけが参戦していた暗号通貨界隈から、一部のマス層に開かれはじめた証拠と言えるかもしれません。
ICOトークンの問題点はこちらの動画にもまとまっています
コイナーぼやき部屋Ep4(10/3/2017) 反省会の反省、TB社とCF社の亀裂とICOの問題点、市場規模に騙されるな
リプレイアタック - Bitcoin Cash導入にあたっての対策 -
Bitcoin Unlimited派のViaBTCが、既存のBitcoinからハードフォークする形で、Bitcoin Cashを導入することを発表しました。Bitcoin Cashは当初8月1日にJihan Wu率いるBitmainが予定していたUAHFベースであり、UAHFのウォレットクライアントであるBitcoin ABCを利用することで使用可能なようです。
最近では、ViaBTCがBitcoinとBitcoin Cashに対して中立な立場を表明するなど、状況が混乱しています。
ビットコインますます分裂 | ビットコインの最新情報 BTCN｜ビットコインニュース
ViaBTC Claims Neutrality Ahead of Bitcoin Cash's Likely Launch - CoinDesk
ただ、Bitcoin自体への影響としては、フォークの際にReplay Attack対策を導入していることにより、既存のBitcoinネットワークでのトランザクション送信は特に問題なく行えるため、そこまで大きな混乱は広がっていないようです。
今回は、そもそもReplay Attackとは何なのか、またBitcoin CashのReplay Attack対策の概要を整理したいと思います。
Bitcoin Cashの公式サイト
Bitcoin Cash - Peer-to-Peer Electronic Cash
前提
ブロックチェーンがある時点で、ハードフォークにより完全に分裂したと仮定します。それぞれのブロックチェーンの名前を以下のように定義しておきます。
元のブロックチェーン (Bitcoin)：A
分裂したブロックチェーン：A1 (元チェーン、Bitcoin)、A2 (分岐チェーン、Bitcoin Cash)
Replay Attack
攻撃方法
リプレイアタックは、以下の流れで発生します。
- 送金者がA1チェーン上で送金
- 攻撃者がその送金トランザクションをコピー
- 攻撃者がA2チェーン上でも送金
これにより、A1チェーン上でのみ送金しようとしていたにもかかわらず、攻撃者によって意図せずA2チェーンでも送金されてしまうことになります。今回の騒動を例にとると、Bitcoinを送金しようとしただけなのに、攻撃者がそのトランザクションをコピーしてBitcoin Cashも送金させられてしまうという攻撃です。
Bitcoin Cashの価値がほとんどなければリプレイアタック対策がなくても問題ありませんが、BitcoinとBitcoin Cashが並存する状況だと、リプレイアタックを恐れてBitcoin利用者が減少してしまうおそれがあります。
Bitcoin Cashにおける対策
この攻撃への対策はシンプルで、A1チェーンとは異なるトランザクションのルールを、ハードフォークしたA2チェーンに導入すれば、A1チェーン上のトランザクションがA2チェーンに取り込まれることはなくなります。逆も然りで、A2チェーンで導入したルールがA1チェーンでは無効なルールであれば、A2チェーン上のトランザクションがA1チェーンに取り込まれることもありません。
今回Bitcoin Cashでは、Sighash Typeと呼ばれるパラメータにSIGHASH_FORKIDという新たなフラグを足すことで、Bitcoin Cashのトランザクションであることを認識しています。Sighash TypeはTransaction Inputに含まれる署名を検証する際 (技術的な話をすると、スタックに積まれた署名を、OP_CHECKSIGによりPublic Keyで検証する際)に、検証の挙動を変更するために利用されています。
この新フラグ(SIGHASH_FORKID)がSighash Typeとしてセットされていると、既存のBitcoinのルールでは正当なトランザクションとは認められなくなるので、Bitcoinのブロックチェーンにこのトランザクションが取り込まれることはありません。
Bitcoin Core抜粋
このコードはBitcoin Coreのクライアントソフト内から抜粋したものですが、「SIGHASH_ALLより小さい」または「SIGHASH_SINGLE」より大きい場合はエラー値が返される仕様になっています。Bitcoin Cashが導入する新たなSighash Typeには、0x40 (=64)をセットする予定ですので、Bitcoin上ではトランザクションが無効として扱われることになります。
Sighash Type
OP_CHECKSIG - Bitcoin Wiki
なお、当たり前ではありますが、このSighash TypeはTransaction Inputに含まれる署名の最終バイトを利用しているため、送金に利用するトランザクションがフォーク前のトランザクションであったとしても、リプレイアタック対策として正しく機能します。
その他のフォーク時の注意事項
UASFが導入されることが取りざたされていた際は、Wipeoutのリスクが騒がれました。Wipeoutを直訳すると「全滅」ですが、その名の通り一度ブロックチェーンに取り込まれたトランザクションが無効化されてしまう事象をさします。これはソフトフォークの場合にのみ発生する事象で、旧チェーンから見て新ルールで作成されたブロックも有効に見えることから発生します。
ざっくりと説明すると、途中までは旧チェーンが新チェーンよりも長く、正当に旧チェーンに取り込まれていたトランザクションがあった際に、新チェーンが旧チェーンより長くなると発生します。旧チェーンのルールでは、新チェーンのブロックも有効に見えるため、ブロックチェーンの長さが長い新チェーンが突如有効になってしまいます（= Reorg）。そうすると、旧チェーンに取り込まれていたトランザクションは無効化されてしまいます。
これに関しては、以下の記事が詳しいので詳細を知りたい方はそちらをご確認ください。
btcnews.jp
なぜか爬虫類の名前ばかりの暗号通貨プロジェクト！Komodoの紹介
インドネシア在住者としては、やはり牛を常食としている地上最強の生物「コモドドラゴン」の名を冠した暗号通貨を避けて通るわけにはいきません。クズコインになる前に内容を共有することで、Komodoユーザーを増やしていきたいと思います。ちなみに、私は残念ながらコインを持っていません。
Komodoとは？
Komodo公式サイトでは、Komodoについて以下のように紹介しています。
Komodo is a Zcash fork that adds the dPoW consensus on top of it and integrates into the SuperNET ecosystem.
KomodoはdPoWコンセンサスアルゴリズムを搭載したZcashのフォークであり、SuperNET ecosystemに統合されている。
Komodo dPoW Whitepaper – Komodo Platform
これだけでは全くわからないので、まずはSuperNET、Zcashを最初に説明し、最後にdPoWとは何かを説明していきたいと思います。
SuperNET Ecosystem
SuperNET Ecosystemとは、Bitcoinに代表される複数の暗号通貨をシームレスに接続するための基盤です。このSuperNET Ecosystemを実現するために、SuperNETチームはKomodoとともにIganaと呼ばれるウォレットを開発しています。
IganaはBitcoinベースの暗号通貨を保管できるウォレットです。IganaウォレットはAtomic Swapを提供しており、Bitcoinベースの通貨間では仲介者なしで、安全な取引ができることを目指しています。このIganaウォレットとKomodoが提供する「dPoW」を利用することで、暗号通貨全体のプラットフォームを構築しようというのがSuperNETが目指す目標です。
これに加えてSuperNETでは、円やドルなどFiatにペグしたアセットを作成することで、暗号通貨だけではなく、Fiatも含めたエコシステムの構築を目指しています。
Q & A: SuperNET, Iguana, and the Role of Komodo — Steemit
Zcash
ZcashはDASHやMoneroなどと並ぶ、匿名系の暗号通貨です。Zcashはzk-SNARKsという仕組みを導入しており、zk-SNARKsを利用することでTransactionを暗号化することができます。KomodoはZcashをフォークして作成したコインであるため、Zcash同様zk-SNARKsを利用して取引を暗号化することができます。
zk-SNARKsの解説記事
Zcash開発チームの記事
Zcash - How zk-SNARKs work in Zcash
Ethereum開発者のVitalikの記事
Quadratic Arithmetic Programs: from Zero to Hero – Vitalik Buterin – Medium
もともとSuperNETのプロジェクトチームは、暗号通貨の「プライバシー」、「スケーラビリティ」、「スピード」を問題視していました。zk-SNARKsを利用することで「プライバシー」の問題の解決を図っています。
残る「スケーラビリティ」の問題は前章で紹介したIganaウォレットによるAtomic Swapと、Komodoが提供するdPoWにより解決を図り、「スピード」の問題は同じくKomodoが提供するdPoWにより解決を目指しています。
dPoW
Bitcoinでは、PoWを採用してハッシュパワーに基づいてブロック承認できる頻度が決まる仕組みをとることで、Sybill Attack（シビルとハイドの二重人格者の話から命名。ハッシュパワーではなく、アドレス単位でブロック承認の機会が平等に訪れる場合、二重人格者のように複数のアドレスを駆使することで、ブロック承認頻度を増やすことができる攻撃）や過去トランザクションが覆されることを防いでいます。
これに対して他の暗号通貨では、Bitcoinと同様にPoWを利用している通貨（Litecoinなど）もありますが、Bitcoinに比べるとハッシュパワーは劣っており、セキュリティの観点でBitcoinに歩があります。また、PoS、PoIなど独自のコンセンサスシステムを利用している通貨（NEMなど）もありますが、ハッシュパワーを担保にしていないため、セキュリティ面でPoWベースのシステムに劣るおそれがあります（たとえば、 時価総額が小さいタイミングで、攻撃者が大量に買占め攻撃を行うと、51%攻撃により一部のトランザクションが無効化されてしまう恐れなどがあります）。
コンセンサスシステムの優越についてはいくつか議論があり、ある程度時価総額が大きくなると、既存のネットワークの過半を占める通貨を獲得することが難しくなることから、PoSに移行した方がセキュリティが高まるという指摘もあります。ただ、少なくとも規模が小さい暗号通貨については、PoWであろうが、PoSであろうがセキュリティリスクはBitcoinよりも劣ってしまいます。
ザキヤマさんのPoWとPoS
そこでKomodoでは、dPoWという仕組みを導入してこの欠点を補うことを目指しています。
図からわかるとおり、Komodoは他の暗号通貨をBitcoinネットワークとつなぐ中間レイヤーとして機能します。Komodoを経由してBitcoinのブロックチェーンにトランザクションをまとめて書き込むことで、作られたばかりでセキュリティ強度が低い暗号通貨であっても、Bitcoinと同等のセキュリティ強度を手に入れることが可能になります。
また、例えばPoSを利用した高速なブロック承認スピードを持つ暗号通貨がKomodoのdPoWを利用することにより、高速な承認スピードとBitcoinが持つセキュリティを合わせ持つことが可能になります。
ちなみに、KomodoブロックチェーンからBitcoinブロックチェーンへのトランザクション書き込みは、Notary Nodeと呼ばれるKomodoコミュニティによって選出された一部のノードが代表して行います。
Komodoの今後
今後はSuperNETとしての暗号通貨基盤を強化するべく、Smart Contractの実行基盤を構築することを目標にして開発が進んでいます。通貨としてのKomodoはEthereumでいうGasのように、プログラム実行の燃料（手数料）として利用される予定です。
ひとつ懸念があるとすると、ICOで調達した資金の一部をBitcoinチェーンへの書き込みに利用しているようですが、ICO資金枯渇後のビジョンが不透明な点でしょうか。おそらく、Komodoチェーンへのトランザクション手数料をBTCトランザクション手数料に流用すると思われますが、Notery Nodeを維持するSunerNET開発チームのインセンティブがなくならないか不安です。
一応、1Komodo = 0.25USDを上回っている限りは維持できるとのことですが、その価格を下回ったときにはKomodoを利用したSuperNETエコシステムは終焉を迎えることになりそうです。ちなみに、現在価格は1Komodo=0.83USDです。
NEM デリゲートハーベスティングの仕組み
日本人はなぜかNEMが好きです。Twitter上ではRippleと並んで、NEMの批判が許されない雰囲気が漂っています。実際にNEMのノード数を見てみると、日本が他を引き離して堂々の1位です。
ちなみに、私が住むインドネシアの状況はというと、
...1ノードもない。今ならインドネシアで最初のNEMノードになれそうですね。どうせなるなら、スーパーノードになりたいので、スーパーノードになるための300万XEMの寄付受付中笑
さて、NEMの魅力ですが、Ethereumほどの自由度はない一方、ドキュメント監査機能（アポスティーユ）やアセットの作成（モザイク）が、デフォルトで簡単にできる点は非常に魅力的ですね。しかしそれ以上に、「ハーベスティング」の存在がNEMの魅力を底上げしている気がします。
そもそもハーベスティングとは
ハーベスティングとは、NEMのトランザクションが詰まったブロックを承認する代わりに、そのブロックに詰め込まれたトランザクション手数料を受け取れる仕組みです。
Bitcoinでもマイニングによってトランザクション手数料を受け取ること（＋新規コインの発行）ができますが、ASICと呼ばれるマイング特化のチップを利用して、ガンガン電気を使わないと収益が上がらない状況です。一方、ハーベスティングは「デリゲートハーベスティング」と呼ばれる方法を使えば、別のノード (NIS)に代わりにブロック承認作業をしてもらうことができ、高性能チップや電気代は必要ありません。
なお、どこかの雑誌がハーベスティングによってXEMが発行されるとアホなことを書いたようですが、ハーベスティングはあくまでも承認したブロックに含まれる取引手数料を受け取るだけなので、XEMが新たに発行されることはありません。
デリゲートハーベスティングの仕組み
デリゲートハーベスティング、一見魅力的ですがどのように動作しているのでしょうか？話を進める前に、少し用語の確認をしましょう。
Importance
NEMのハーベスティングはImportanceと呼ばれる、各アカウントに割り振られたスコアによってハーベストできる確率が変動します。インポータンスは主に保有しているNEMの量で決まりますが、それに加えて取引頻度や取引量なども考慮されて決定されます。
ローカルハーベスティング
デフォルトのハーベスティング設定では、デリゲートハーベスティングではなく、ローカルハーベスティングが行われます。その名の通り、リモートのノード（NIS、NEM Infrastructure Server）ではなく、自身のPC上で動作しているノード (NIS)を利用してブロックの承認作業が行われます。
ローカルハーベスティングを行う際は、自身のアドレスにひもづく秘密鍵が自PC上のNISに渡されて、NISはその秘密鍵を利用してブロックに署名を行い、ブロックの承認を行います。なお、これはデリゲートハーベスティングでも同様ですが、ハーベスティングするには10,000XEM以上のXEM（正確には、VestedされたXEM）を保有している必要があります。
デリゲートハーベスティングとは？
さて、ハーベスティングを行う際には、ローカルハーベスティングで見た通り、自分自身の秘密鍵をノード（NIS）に渡す必要があります。しかし、秘密鍵を渡すということは、秘密鍵を受け取ったノードが自分のアドレスをコントロールできることを意味します。
自分が管理していないリモートノード（NIS）に代理でハーベスティングをしてもらう場合は、そのままだと自分が持っているXEMをリモートノードに奪われてしまうリスクがあるので、ちょっとした工夫が必要になります。デリゲートハーベスティングではブロック承認専用の「代理アカウント」を作成することで、この問題を解決しています。
まず、デリゲートハーベスティングでは、実際にハーベスティングを始める前に、NEMブロックチェーン上にトランザクションを送信します。このトランザクションは、自分自身のアカウント（以降、「本体アカウント」）が保有するImportanceを「代理アカウント」にマッピングします。これにより、代理アカウントは本体アカウントが保有するImportanceを利用して、ハーベスティングに参加することができるようになります。
このトランザクションはNEMのダッシュボードでは、「インポータンストランスファートランザクション (Importance Transfer Transaction)」と表示されます。その名の通り、本体アカウントのImportanceを代理アカウントにTransferしているということですね。
代理アカウントはあくまでも本体の「代理」であり、代理アカウントは1XEMも保有していないので、安心して代理アカウントの秘密鍵をリモートノード（NIS）に渡すことができます。本体アカウントが持つImportanceの情報をもとにして、代理アカウントにブロック承認の機会をあたえられた場合には、リモートノード（NIS）が受け取った代理アカウントの秘密鍵を利用して、承認作業を実行します。
承認後、トランザクション手数料を受け取ることができますが、代理アカウントのアドレスにXEMを振り込むと、秘密鍵を保有しているリモートノード（NIS）に、そのXEMを奪い取られてしまうおそれがあります。そこで、ハーベスティングしたトランザクション手数料は、本体アカウントのアドレスに対して振り込むようにすることで、リモートノード（NIS）がトランザクション手数料を奪い取ることができない仕組みにしています。
How Local and Delegated Harvesting Works
デリゲートハーベスティングを維持する理由と仕組み
デリゲートハーベスティングが存在することで、NEMではImportanceに応じて平等にブロックの承認機会が与えられることになります。Bitcoinではブロック承認機会が特定のマイナーに集中してしまっていますが、NEMではネットワーク利用者にネットワークへの貢献度に応じて平等にブロック承認機会（=トランザクション手数料の受け取り）が巡ってくることになります。
また、ハーベスティングを代理で実行してくれるリモートノードにインセンティブがないように思われますが、リモートノードのほとんどはスーパーノードと呼ばれるノードです。スーパーノードは取引手数料とは別に、NEM Supernode Rewards Programと呼ばれる財源からスーパーノード維持の対価としてXEMをもらうことができるため、ノードを維持するインセンティブが生まれています。
スーパーノードについて詳しくはこちら
cryptocoin.hatenablog.com
Layer2解説 第2回 アトミックスワップ
前回、マイクロペイメントチャネルについて解説記事を書きました。通常の順序で行くと、次の記事はライトニングネットワークになりますが、ここではいったん寄り道をしてアトミックスワップ（atomic swap）を先にご紹介したいと思います。
というのも、マイクロペイメントチャネルとアトミックスワップの仕組みは似ており、マイクロペイメントチャネルを理解していると、アトミックスワップの話がスムーズに頭に入ってくるからです。また、アトミックスワップで使われる手法はライトニングネットワークでも利用されていることから、先にアトミックスワップを理解することでライトニングネットワークの理解が容易になります。
目次
そもそもアトミックスワップとは？
アトミックスワップとは、異なるチェーン（コイン）間でコイン交換を実現する方法です。通常、コインの交換（例えばBitcoinとLitecoinの交換）には取引所が使われますが、その場合には取引所を信頼する必要があります。例えばBitcoinからLItecoinに交換したいときに、Bitcoinを取引所に預けた後でその取引所がBitcoinを持ち逃げすると、一時的であっても預けていたBitcoinが取引所に奪われてしまいます。
また、「Bitcoinを持つAlice」と「Litecoinを持つBob」との間で相対でコイン交換をしようとしても、AliceがBitcoinをBobに渡した後で、BobがAliceにLitecoinを渡さずに逃げてしまう可能性があります。当然逆もしかりで、先にBobがAliceにLitecoinを渡したとしても、Aliceが受け取ったLitecoinを持ち逃げしてしまうおそれがあります。
この問題に対応するべく、P2P取引所のひとつであるBitsqureでは「仲介人」という仕組みを利用しています。例えば、当事者間で認識齟齬、紛争が発生した場合には、仲介人の判断で送金の実施、キャンセルができるようになっています（2 of 3マルチシグを利用）。しかし、この手法は仲介人の判断に依存しており、真にトラストレスということはできません。
注目が高まる分散型オープンソース・エクスチェンジ「Bitsquare」とは | ビットコインの最新情報 BTCN｜ビットコインニュース
Bisq - The decentralized Bitcoin exchange
アトミックスワップは第三者を介さず、なおかつトラストレスにコインの交換を行うことができるため、これらの問題を解決することができます。
アトミックスワップ理解のための前提 スクリプト
「Bitcoinを送金する」とよく言いますが、実際には、Transaction Outputを送金先の人にロックすると言ったほうが今後の話を理解しやすくなります。
例えば、「AliceがBobにBitcoinを送金したい」場合、AliceはトランザクションのOutputにBobだけが解読できる情報を記載します。これで、このTransaction Outputは、誰もが使えるわけではなく、Bobに"ロック"されている状態になります。BobはBobが持っている秘密の情報を利用してトランザクションのInputに署名することで、そのTransaction Outputを利用することができるようになります。このOutputには、上記例のように「Bobだけが解読できる情報」を埋め込むこともできますし、「AliceとBobの2人が揃わないと解読できない情報（マルチシグ、2 of 2）」のような複雑な条件も埋め込むことができます。
また、このスクリプトはチューリング完全ではないものの、一種のプログラム言語として動作するので、単純な条件分岐処理を埋め込むこともできます（詳しくは、OP_IFで検索してみてください）。
スクリプトについてはこちらにまとめています
cryptocoin.hatenablog.com
アトミックスワップの仕組み
前回同様、マルチシグとタイムロックが登場します。また、先にマイクロペイメントの仕組みを理解した方が理解が早いと思うので、まだ前回の記事をお読みでない方は先にそちらを読むことをオススメします。
基本的な流れ
基本的な流れは以下の通りです。
- AliceがBobにBitcoinを渡すトランザクションを作成する。但し、このトランザクションを使用するにはBobの署名と、Aliceが持つ秘密情報 (X)が必要 (BTC Pay Transaction)
- BobがAliceにLItecoinを渡すトランザクションを作成する。但し、このトランザクションを使用するにはAliceの署名と、Aliceが持つ秘密情報 (X) が必要 (LTC Pay Transaction)
- LTC Pay TransactionをAliceが使用して、AliceはLItecoinを手にいれる。このとき、Aliceの持つ秘密情報 (X) もブロードキャストされる
- BTC Pay TransactionをBobが使用して、BobはBitcoinを手にいれる
勘の良い方はお気づきかもしれませんが、秘密情報（X）がアトミックスワップの実現のために重要な鍵となります。それでは順をおって、処理の流れを見ていきましょう。
1. AliceがBobにBitcoinを渡すトランザクションを作成する (BTC Pay Transaction)
Aliceは、BobにBitcoinを渡すトランザクションを作成します。正確に言うと、Aliceは、以下の情報のいずれかがないと解読できないTransaction Outputを作成します。
BTC Pay Transactionの利用条件
1) BobとAliceの両方の署名（マルチシグ、2 of 2）
2) Bobの署名とAliceだけが知るXという情報
利用条件2)で登場したXは、Aliceが任意に選ぶことができる乱数です。AliceはこのXを公開せずに、手元にとっておきます。最終的にこのXという情報をBobが署名とともにブロードキャストすると、BobはこのTransaction Outputを利用することができます。
以下の引用は、具体的なTransaction Outputの例になります。以下のスクリプトの6行目 (OP_HASH160から始まる行)のように、Xにハッシュをかけた値 (H(x))を、Transaction Outputに埋め込んでおきます。このトランザクションを利用したいBobは自分の署名とともにXをTransaction Inputに埋め込みます。もし、Xにハッシュをかけた値がH(x)となれば、Bobはこのトランザクションを利用できるということになります。
OP_IF
// Refund for A
2 <pubkeyAlice> <pubkeyBob> 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for B
OP_HASH160 <H(x)> OP_EQUAL <pubkeyBob> OP_CHECKSIGVERIFY
OP_ENDIF
Alt chains and atomic transfers
さて、このトランザクションをマイクロペイメントでいう「Deposit」としてブロードキャストするわけですが、Bobが失踪してもAliceがDepositした金額を回収できるように、ブロードキャストの前にRefund Transactionを作成する必要があります。もちろん、AliceがDepositしたBitcoinをすぐには引き出せないように、Refund TransactionにはTimeLockをかけておきます。
Refund TransactionにAliceとBobが署名することで、BTC Pay Transactionの利用条件1)を満たしますので、もしBTC Pay Transactionが利用されずにTimeLock期限が到来したら、AliceはいつでもこのDepositした金額を回収することができます。
2. BobがAliceにLitecoinを渡すトランザクションを作成する (LTC Pay Transaction)
続いて先ほどとは逆に、BobがAliceにLitecoinを渡すトランザクションを作成します。手順1. とほぼ同じことを実施するのですが、一点だけ注意が必要です。それは、Bobがトランザクションを作成する際にも、BTC Pay Transactionで利用したのと同じH(x)を条件式に利用することです。
OP_IF
// Refund for A
2 <pubkeyAlice> <pubkeyBob> 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for B
OP_HASH160 <H(x)> OP_EQUAL <pubkeyAliceb> OP_CHECKSIGVERIFY
OP_ENDIF
ハッシュ関数は一方向関数であり、元の数字からハッシュ値を導くことは容易にできますが、ハッシュ値から元の数字を導くことは（ほぼ）不可能です。つまり、H(x)からXを導くことはできませんから、Aliceは安心してH(x)をBobに伝えることができます。
3. LTC Pay TransactionをAliceが使用する
1.で見た通り、AliceはXという値を知っています。そのためAliceは、LTC Pay Transactionを即座に利用可能です。
4. BTC Pay TransactionをBobが使用する
3.でAliceがLTC Pay Transactionを使用するまで、BobはBTC Pay Transactionを使用することはできませんでした。しかし、3.でAliceがLTC Pay Transactionを使用したことで、BobはXの値を知ることができたので、BobもBTC Pay Transactionを使用することができます。
以上の通り、AliceとBobはお互いを信頼することなく（トラストレスに）、お互いが持っていたBTCとLTCを交換することができました。
まとめ
マルチシグとXという秘密情報を導入することで、二者間でトラストレスに通貨の交換ができました。今回登場したXという秘密情報を利用するアイデアは、最近話題のライトニングネットワークでも鍵となる考え方です。
ライトニングネットワークの場合は第三者を中継してBitcoinを送金するため、途中でBitcoinを中継者に持ち逃げされてしまうおそれがあります。Xという秘密情報を導入することで、最終的な受取人にBitcoinが渡った後でないと、中継者はBitcoinを受け取れないという仕組みにしています。詳細は次回！
Layer2解説 第1回 マイクロペイメントチャネル
BitcoinでLightning Networkを実現する方法はいくつか提唱されていますが、いずれの実装方法もマイクロペイメントチャネルを拡張することで実現しようとしています。今回は、マイクロペイメントチャネルの仕組みを見ていきたいと思います。
目次
マイクロペイメントチャネルの概要と理解のための前提
マイクロペイメントチャネルとは、二者間でブロックチェーンを利用せずに複数回の少額送金を実施するための技術です。複数回の少額送金をブロックチェーン上で実施しようと思うと以下のような問題に突き当たります。
送金者側の負担：取引ごとの手数料
現在Bitcoinでは1トランザクションあたり、数十円から数百円の手数料がかかっており、例えば継続して少額の決済をするような場合（例えば、ガス代金の支払いなど）には、毎回毎回手数料がかかることで手数料負担が重くなってしまいます。
受取人側の負担：非効率なトランザクションによる手数料上昇
少額決済を繰り返すと、ウォレットの中には細かな単位のBitcoinが積み重なることになります。Bitcoinの取引手数料は、送金額ではなく、送金トランザクションのサイズで決まるため、それらのBitcoinを送金に利用しようとすると、トランザクションサイズが大きくなり、取引手数料が高くついてしまいます。
マイクロペイメントチャネルを利用すると、一定期間の間に実行された送金/受金を相殺して一つのトランザクションにまとめた上でブロックチェーンに書き込むため、送金者の取引手数料を節約することができます。また、トランザクションがひとつにまとまるので、受け取ったトランザクションを利用するときにトランザクションサイズが大きくなることも防げます。
さて、これからマイクロペイメントチャネルの仕組みを解説していきますが、マイクロペイメントチャネルを理解するにはいくつかの前提となる知識をおさえる必要があります。
- マルチシグ (2 of 2)
- Locktime
（トランザクションの構造（Input / Output）はわかっている前提です。）
マルチシグ
通常のBitcoinの送金は、「送金先のアドレス」を指定します。アドレスはPublic Keyに対してハッシュ値をかけたものなので、この送金方法をP2PKH (Pay-to-Public-Key-Hash)と呼びます。この場合、受け取ったBitcoinを受取人が使うためには、受取人であることを証明するために受取人の秘密鍵で送金トランザクションに対して署名する必要があります。
これに対して、複数人が署名することで、はじめてBitcoinを利用できるということにしたい場合があります。例えば、企業の調達部門が資材の対価をBitcoinを使用して支払う場合に、調達担当者に加えて経理担当者の承認を必要とするといった場合です。これを実現するのがマルチシグです。
マルチシグを使いたい受取人は、まず受取人のPublic Key全て（上の例の場合は、調達担当者と経理担当者のPublic Key）を送金者に教えます。送金者は受け取ったPublic Keyの両方を受取人とする形で、トランザクションを作成しネットワークに送信します。受取人は、受取人全員（上の例では、調達担当者と経理担当者）が署名したトランザクションをネットワークに送信することで、受け取ったBitcoinを送金に利用できます。
なお、マルチシグは一般的に「2 of 2」のように、「数字1 of 数字2」の形で表現されます。数字2は受取人の数を表し、数字1は受け取ったBitcoinを利用するために必要な署名の数を表しています。例えば「1 of 2」の場合は、受取人は2人いますが、受け取ったBitcoinを利用するには2人のうち1人の署名があれば十分ということになります。
Locktime
「一定時間経過しないとBitcoinを利用できない」ということを実現するための仕組みがLocktimeです。
送金者はLocktimeにブロックの高さ、または時刻を指定します。指定されたブロックの高さ、または時刻以降にならないと、そのトランザクションは各ノードに伝播されたり、ブロックに取り込まれたりすることはありません。
マイクロペイメントチャネルの仕組み
話を簡単にするため、例を用いて説明していきます。登場人物は以下の通りです。
Alice：Bitcoin送金者。ガス会社であるBob Corporationと契約してプロパンガスを利用している。
Bob：Bitcoin受取人。Bob Corporationを経営している。
基本的な仕組み
マイクロペイメントチャネルでは、AliceとBobのマルチシグアドレスに対して、Aliceが一定額のBitcoinをDepositすることで取引開始となります。ここでは仮に、Aliceがマルチシグアドレスに対して、10 BTCをDepositしたと仮定して話を進めます（このDepositトランザクションをOpening Transactionと呼称することとします）。
Opening Transactionをブロードキャストする前に、Aliceの10BTCがマルチシグアドレスにロックされたままにならないように下準備が必要になります。例えば、以下のような事態が考えられます。
- Bob Corporationが倒産
- Aliceがガス会社を乗り換えようと思った時に、Depositしている10BTCをBob Corporationに人質として取られる
この事態を防ぐため、Opening TransactionのDeposit額全額（10 BTC）をAliceに返金するトランザクションにAliceとBobが署名して、Aliceがそのトランザクションを保持しておきます (以後、Refund Transactionと呼称します)。また、すぐにDepositがAliceによって引き出されることを許容すると、今度はBob CorporationがAliceに騙されてしまうおそれがあるため、このトランザクションにはLockTimeを設定しておきます。例えば、ガス契約期間を1ヶ月間と仮定して、このトランザクションが利用できる日を1ヶ月後のX月31日としておきましょう。BobはX月31日を過ぎた後もマイクロペイメントチャネルを閉じないでいると、このトランザクションによって全額をAliceに戻されてしまうので、X月31日までにマイクロペイメントチャネルを閉じる必要があります。
さて、Bob CorporationはAliceとガス契約を結んでいます。話の単純化のために、Aliceが１回ガスを使用すると、使用量に関わらずAliceはBobに対して1BTCを支払わなければならないとします。
X月1日、Aliceはガスを一回利用しました。AliceはBobに対して1BTCを支払わなくてはなりません。そのために、AliceはOpening TransactionをInputに利用したトランザクションを作成してAliceの署名を施し、Bobに対してこのトランザクションを送信します (以後、Pay-to-Bob Transaction1と呼称します)。この時点ではまだBobの署名がなく、ブロードキャストされていないため、このトランザクションがブロックチェーンに書き込まれることはありません。
Pay-to-Bob Transaction1
■Input
Opening Transaction
■Output
to Bob Address 1BTC
to Alice Address 9BTC
BobはもうこれでAliceとの契約を終わりにしたければ、Aliceへのガス供給をストップして、Pay-to-Bob Transaction1にBobの署名を加えた上で、他のノードにブロードキャストします。しばらくした後、このPay-to-Bob Transaction1はブロックチェーンに書き込まれて、取引が確定します。すなわち、マイクロペイメントチャネルがクローズされることとなります。
ここでは、BobはAliceと引き続き契約を継続したいため、このトランザクションをブロードキャストせず、Bobの手元にとっておいたとします。
X月2日、Bobの思惑通り、Aliceは再びBob Corporationの高額なガスを利用したため、AliceはBobに1BTCを追加で支払わなければなりません。ここでAliceは新たなトランザクションを作成して、Aliceの署名を加えた上でBobにこのトランザクションを渡します（Pay-to-Bob Transaction2とします）。
Pay-to-Bob Transaction2
■Input
Opening Transaction
■Output
to Bob Address 2BTC
to Alice Address 8BTC
このトランザクションはPay-to-Bob Transaction1と同様に、Opening TransactionのOutputをInputとして消費します。同じOutputが二回使われることはないため、Pay-to-Bob Transaction1とPay-to-Bob Transaction2は両方とも利用されることはなく、どちらか片方だけが利用されることになります。受け取ったBobが取引を確定させたい場合は、当然受け取る額が大きいPay-to-Bob Transaction2をブロードキャストすることになります（仮にBobがPay-to-Bob Transaction1をブロードキャストした場合は、Bobは1回分のガス利用料を取り逃がすことになります。Bobが損するだけなので、Bobがそれを選ぶのは自由ですが、BobがPay-to-Bob Transaction1をブロードキャストするインセンティブはありません）。
双方向での送金
さて、Aliceはここに来てやっと、ガス料金が高すぎることに気づきます。Bobに文句を言い、ガス料金を1回あたり1BTCから、1回あたり0.1BTCに減額してもらうことができました。しかも、過去分にも遡求して適用してくれるそうです。
BobはAliceに対して1.8BTC (2 - 0.2)を返金する必要があります。通常の取引であれば、BobからAliceに1.8BTCを送るだけですが、せっかくなので既に作られているマイクロペイメントチャネルを利用して返金することにします。返金するためには、以前の取引をなかったことにして、新たに0.2BTCをAliceからBobに送ることにすればよさそうです。そこでAliceは、以下のトランザクションを作成・署名して、Bobに送りました。
Pay-to-Bob Transaction3
■Input
Opening Transaction
■Output
to Bob Address 0.2BTC
to Alice Address 9.8BTC
これに安心したAliceは、Bob Corporationは返金に応じてくれて、Bitcoinも使えるいい会社だと友達にも紹介し始めます。紹介された友達はAliceの勧誘に応じて続々とBob Corporationと契約を結びました。
しかし、Bob Corporationの経営は悪化していました。できる限りのBitcoinを受けとった上で計画倒産するべく、最後に送られてきたPay-to-Bob Transaction3ではなく、2BTCを受け取ることができるPay-to-Bob Transaction2をブロードキャストして、ペイメントチャネルをクローズしてしまいます。これにより、Aliceは0.2BTC支払うだけでよかったはずが、2BTCを支払うことになってしまいました。さらには勧誘した友達からもそっぽを向かれてしまいます。Aliceは裁判所で戦うことを決意しました。
このままAliceとBobの法廷闘争を続けてもいいのですが、法廷闘争になる前にこの事態を防ぐことはできなかったのでしょうか？よくよく考えてみると、Bobの詐欺行為を防げなかった原因は過去分のトランザクションを取消しできていなかった点にありそうです。
過去トランザクションの取り消し
それではどのようにすれば、過去トランザクションを取消すことができるでしょうか？ここでは再びマルチシグとLocktimeを利用することで、この問題を解決します。どういう発想をするかというと、「もし過去のトランザクションをBobが使ってしまった場合、Depositしていた全額をAliceに戻してしまうという約束にしておけば、Bobが過去のトランザクションを使うインセンティブをなくすことができる」と考えます。
さて、AliceとBobのマルチシグにAliceが10BTCをDipositしたところまで時間を遡ります。
今回Aliceは、Bobに騙されない方法を考案しました。最初の1BTCのガス代支払いのために、Aliceは以下のPay-to-Bob Transaction1をBobに送ることにしました。
Pay-to-Bob Transaction1
■Input
Opening Transaction
■Output
to マルチシグ (Bob Temporary Address1 & Alice Address) 1BTC
to Alice 9BTC
騙されてしまった最初のPay-to-Bob Transaction1からの変更点は、「Bobに1BTCを送金するOutoput」が、「マルチシグへ1BTCを送金するOutput」になっている点です。注意が必要なのは、マルチシグで使われているBobのAddressはTemporary、つまり捨てアドレスである点です。ここではその意味には深く入らず、先に進むことにします（後で過去トランザクションを無効化するタイミングで、なぜ捨てアドレスを利用したかがわかります）。
さて、Bobが1BTCを最終的に獲得するには、このトランザクションに加えて、マルチシグからBob Addressへの支払いトランザクションを作成する必要があります。そこで、Aliceは以下のトランザクションに署名して、Bobに送っておきます。なお、このトランザクションにはLockTimeを設定しておきます。ここではOpening TransactionのLocktimeより1日だけ前のX月30日にLockTimeを設定しておきましょう。
Pay-to-Bob Transaction1-a
■Input
Pay-to-Bob Transaction1
■Output
to Bob 1BTC
LockTime付き
Bobは1BTCの受け取りで取引を確定させたければ、Pay-to-Bob Transaction1とPay-to-Bob Transaction1-aトランザクションに署名をしてブロードキャストすれば取引を確定できます（Locktime分、受け取りを待つ必要はありますが）。
さて、Aliceはガスを再び利用してしまったので、もう1BTCを支払う必要があります。今回はPay-to-Bob Transaction2を送るのに加えて、過去分のトランザクション（Pay-to-Bob Transaction1）を取り消してみたいと思います。まずは、さきほどと同様にAliceはトランザクションを作成します。
Pay-to-Bob Transaction2
■Input
Opening Transaction
■Output
to マルチシグ (Bob Temporary Address2 & Alice Address) 2BTC
to Alice 8BTC
このトランザクションをBobに送り、Bobがこの新規トランザクションの状態を承認した場合は、BobはBob Temporary Address1を作成するのに利用した秘密鍵をAliceに送ります。これで準備完了、Bobは過去のトランザクションを使えなくなりました。捨てアドレス (Temporary Address)を使用していたのは、秘密鍵をAliceに暴露するためだったのです。
ここで例えばBobがTransaction1を誤ってブロードキャストしたとします。Bobとしては「Pay-to-Bob Transaction1-a」を利用して、BitcoinをBobのアドレスに送ろうと考えます。しかし、このトランザクションはLocktimeが設定されていてX月30日までは送金を確定することはできません。そこでAliceは、約束を破ったBobに対して制裁を加えるべく、さきほど受け取った「BobのTemporary秘密鍵」と「Aliceの秘密鍵」を利用して、以下のトランザクション (以下、Remedy Transactionと呼称します)を作成してブロードキャストします。これにより、AliceはDipositしていた10BTC全額を回収することができます。
Remedy Transaction
■Input
Pay-to-Bob Transaction1
■Output
to Alice 1BTC
このように、Bobが過去のトランザクションを使用した場合には、Aliceは（LockTimeが到来するまでは）いつでもDepositしていた全額を回収可能ですので、Bobが過去のトランザクションを利用するインセンティブはなくなります（今の例ではそもそもBobが過去トランザクションを利用するインセンティブはありませんでしたが、Transaction3を作成した時のようにBobの取り分が少なくなるパターンでは、Bobが過去トランザクションを利用するインセンティブが生まれるので、このような仕組みで過去のトランザクションを無効化する必要があります。）
以上の通り、過去トランザクションを取消すことができました。あとは、Bobが最新のトランザクションを確定させたくなったら、最新トランザクションをブロードキャストすることで、トランザクションをブロックチェーンに書き込み、いつでもペイメントチャネルを閉じることができます。
さらに、Aliceの側からもペイメントチャネルを閉じることができるように、Bobもトランザクションを作成・署名してAliceに渡しておくというステップを追加すれば完成です。ここは大した話ではないと思うのですが、文章で書くとダラダラ長くなってしまうので、詳細を知りたい方は以下のリンクの解説記事その1をご覧ください。
Layer2解説、第2回はアトミックスワップ
cryptocoin.hatenablog.com
参考資料
概要記事
http://doublehash.me/micropayment-bitcoin/#more-1083
ビットコインの Lightning Network メモ
Working with micropayment channels (英語)
解説記事 (英語)
解説記事その1。体系的にまとまっていて、なおかつわかりやすい。
Lightning Networks Part I: Revocable Transactions – Rusty Russell's Coding Blog
解説記事その2。Lightning Networkの解説資料だが、前半はほぼマイクロペイメントチャネルの説明。詳細解説版。
https://lightning.network/lightning-network-paper.pdf
マルチシグやLocktime
安定のMastering Bitcoin。
Mastering Bitcoin: Unlocking Digital Cryptocurrencies
- 作者: Andreas M. Antonopoulos
- 出版社/メーカー: O'Reilly Media
- 発売日: 2014/12/03
- メディア: Kindle版
- この商品を含むブログを見る
Ethereumプロジェクト紹介 第2回 EncryptoTel
前回の「Ethereum プロジェクト紹介」では、Melonportを取り上げました。今回は、ICO情報サイトのcoinscheduleの情報を元に、直近のEtheruem ICOに関わるプロジェクトを見ていきたいと思います。まずは、EncryptoTelを取り上げます。
Coinschedule - The best cryptocurrency ICO list. Only selected ICO crowdfunding projects
掲載予定
EncryptoTel (今回)
MobileGO
Veritaseum
Back To Earth
Populous
FundRequest
(*) ここに掲載しているプロジェクトは、これから調査予定で、現時点では詳細を調べていません。ここに掲載する情報は投資をオススメするものではなく、ただの調査リストとお考えください。
前回の記事
cryptocoin.hatenablog.com
EncryptoTel
公式サイト
Encrypto Telecom
Whitepaper
http://ico.encryptotel.com/assets/pdf/EncryptoTel_WP_v1.pdf
このプロジェクトでは、SkypeやLine通話のようなWeb通話を暗号化することで、個人間、企業間の通話を盗聴から防ごうというプロジェクトです。公式サイトでは個人間の通話に関しても情報が掲載されていますが、メインとなるターゲットは企業で使用されているPBX（後ほど記載）を、EncryptoTelでリプレースすることのようです。
具体的な使用方法ですが、ZoiperなどのIP電話の統合管理ソフトと接続して利用する形になるようです。設定方法はこちらのPDFにまとまっています。
https://encryptotel.com/files/OtherMobile.pdf
PBX
PBXとはPrivate Branch Exchange (構内交換機) の略で、企業内で電話交換をするための装置になります。いわゆる、「内線」を実現するための機械、仕組みです。最近では複数拠点間でIP通信を実現し、電話代を抑えることが可能なクラウド型PBXも登場しています。EncryptoTelはこのクラウドPBXの一種としてカテゴライズできるかと思います。
基礎から始めるIP-PBX[第1回 IP-PBXのイメージを掴もう] | Call Center Trends
クラウド全般にいえることですが、企業がクラウドを導入しようというときに最も懸念する点が「セキュリティ」です。複数社で機能を共有することで規模の経済が働くため、一般的にクラウドのほうがコスト面で優れていますが、外部ネットワークに接続する必要があることから、盗聴の危険性は少なからず上昇します。これに対して、例えばクラウドベンダーのAWSなどではVPNだけではなく、専用線の引き込みを認めるなどしてセキュリティに対する懸念払拭に取り組んでいます。
仕組み
さて、肝心のEncryptoTelのWhitepaperを読んでみます。しかし、残念ながら、Whitepaperを読んでも思想やら、提供予定の機能紹介ばかりで、技術的な仕組みが全く書かれていません（笑）。推測100%ですが、以下のような感じかと考えています。
ユーザ登録機能：ブロックチェーンを利用
PBX機能：ブロックチェーンを利用＋PBX用のスーパーノードを構築 (?)
通話履歴管理＋課金機能：ブロックチェーンを利用
通話機能：通常のP2P通信を利用
例えばSkypeでは、ユーザ登録情報を中央のサーバで一元管理しています。その部分は確かに中央集権的な仕組みを利用せずとも、ブロックチェーンを利用することができるのでサーバ構築・運用費用分のコスト削減は可能かと思います。
また、ブロックチェーンとは一切関係がありませんが、Bitcoin / Litecoinでの利用料支払いを認めることで (他にはUSD, EURで支払いが可能)、通話通信だけでなく、支払いに関しても匿名性を担保しようとしています。
開発方針
現在β版としてEncryptoTelがサーバを保有する形でのクラウド型システムを提供しているようです。ICOにより開発資金を集め、現在のクライアントサーバ型のシステムから、ブロックチェーンを利用したシステムに変更を図っているようです。
トークンの用途
トークンはPBXやIP通話の利用料の支払いに利用されるようです。BitcoinやLitecoinでの支払いも同様に認めるようですが、ETT (EncryptoTel Token)を利用した場合は、ディスカウントすることでETT保有意欲を高める政策です。それに加えて、ETTを保有することで、EncryptoTelの意思決定への参加や、経営状況を確認するサイトへのアクセスができるようになる予定です。
The EncryptoTel Token (ETT): fuel for our telecommunications ecosystem
また、トークンの管理方法は少し特殊な方法を採用しており、EtheruemとWavesの2環境でシームレスにトークンを保持する仕組みになっています。この仕組みの実現には、Blockswapが利用されています。ちなみにBlockswapは次号でお届けする予定の、「MobileGo」でも使用されており、ICOの際のスタンダードになりつつあるのかもしれません。
What is BlockSwap and why will MobileGo use it? — Steemit
WavesとEthereum上に同時にトークンを存在させることができる仕組み。スマートコントラクトで実装してるが、Waves側はサーバーで残高管理する。ネットワーク効果を拡張する技術。通貨の淘汰よりもこれも一つ解かも。https://t.co/ZBd6PUbdU5
— ふーさん ( ぬこイナー ) (@chubchubkun) 2017年4月22日
問題点
PBXの仕組みをどのようにブロックチェーン上で実現するつもりなのかの詳細がありません。PBXを実現するためには、当然ですがPBX内のネットワークと外部の電話網を接続する必要があります。当然ブロックチェーン上でPBXを実現しようとする場合も同様で、ブロックチェーンを保持する各ノードから既存電話網に接続されている必要があります。
通話だけを行うノードもブロックチェーン上に存在すると仮定すると、一種のスーパーノードとしてPBXノードを定義する必要があります。仮にこのPBXノードをEncryptoTelが維持する構成だとすると、結局既存のクラウド型PBXとやっていることは同じになりますので、ブロックチェーンを利用する必要がまったくありません。
唯一新規性があるとすれば、ペイメントまで含めた匿名化ですが、これに至ってはPBX用のブロックチェーンとは一切関係ないため、例えば既存のPBX業者がBitcoin支払いを認めたらそれだけで新規性は失われてしまいます。
肝心の通信暗号化にしても、Skypeなどでも既に採用されているTLSを利用しているだけで新規性は全くなく、ブロックチェーンを利用する必要性も特にありません（おそらく通信はSkypeなどと全く同様のP2P通信でしょう）。
