BitCoinに関する質問

Satoshiさん、こんにちは。

あなたのBitCoinに関する論文を大変興味深く読んだ。しかし少し分かりにくいと感じた――いくつかの例を示してもらえれば、より理解しやすくなると思う。

具体的には、ブロックに何が含まれているのかがよく分からない。私の理解が正しければ、すべてのトランザクションがハッシュ化されるグローバルなチェーンは1つ（あるいはいくつか）だけだ。いわば「経済の物語」を記録するチェーンが1つしかないとすれば、どのようにスケールするのだろうか？仮に地球規模で展開された場合、毎時数百万、あるいは数十億のトランザクションがチェーンにハッシュ化されることになる。各PoWが1つのブロックに多くのトランザクションをまとめられることは理解しているが、それでもハッシュ化するデータ量は膨大だ。もし複数のチェーンがある場合、ネットワークを圧倒することが依然として困難であるように、トランザクションは各チェーンにどのように割り当てられるのだろうか？例えば、10個のグローバルチェーンがある場合、システムを打ち負かすために必要なCPUパワーは以前の10%に過ぎない。

また、1コア＝1票という前提が妥当かどうかも疑問に思う。ノードの大多数が標準的なコンピュータ上にある場合、攻撃者がFPGAやカスタムASICを使用して大幅に優れたパフォーマンスを得られる可能性が高いように思える。カスタムハードウェアを使ってチェーンを打ち負かすことについて、どのようにお考えだろうか？

インセンティブに関するセクションは理解しにくいと感じた。特に、ノードを運営する理由として新しいコインを鋳造することから、取引手数料を課すことへの移行が何によって引き起こされるのかが明確ではない（そもそもBitCoinの要点は取引コストをゼロにすることではないのだろうか？）。おそらくシステムを管理する人間がいて――例えばあなたが2,400万枚のコインが適切な数だと何らかの方法で決定し、「このタイムスタンプ以降に鋳造されたコインはN+1のゼロビットプレフィックスを持たなければならない」というルールファイルを配布し、正直なノードがそれを強制するのだろう。

v1のインフレスケジュールはどのように決定されたのだろうか？2,400万枚のコインという数字はどこから来たのだろうか？これらのコインの額面は何だろうか？価値を結合・分割する方法について言及されているが、これがどのように機能するのかよく分からない。例えば、ビットコインは常に整数で表されるのか、それとも小数のビットコインを持つことができるのだろうか？

質問がたくさんだ :) しかし、真に革命的なアイデアに出会うことは稀だ。新しい通貨スキームにこれほど興奮したのは、Rippleを発見して以来だ。Rippleについて何かお考えがあれば、ぜひ聞かせてほしい。

よろしく。 -mike

Mikeさん、こんにちは。

ご質問にお答えできることを嬉しく思う。時間があれば、論文を補足するFAQを書くべきだな。

グローバルなチェーンは1つだけだ。

既存のVisaクレジットカードネットワークは、世界中で1日あたり約1,500万件のインターネット購入を処理している。Bitcoinは既存のハードウェアで、そのコストのわずかな部分で、すでにそれよりもはるかに大きくスケールできる。スケールの上限に達することは本当にない。興味があれば、極端なサイズにどのように対応するかについて説明できる。

ムーアの法則により、ハードウェアの速度は5年で10倍、10年で100倍になると予想できる。Bitcoinが驚異的な普及率で成長したとしても、コンピュータの速度はトランザクション数の先を行き続けると考えている。

手数料がすぐに必要になるとは予想していないが、ノードを運営することが負担になりすぎた場合、取引手数料を含むトランザクションのみを処理するノードを運営することは可能だ。ノードの所有者が受け入れる最低手数料を決めることになる。現時点では、そのようなノードは何も得られない。なぜなら誰も手数料を含めていないからだ。しかし、十分な数のノードがそうした場合、ユーザーは手数料を含めればより速い承認を得られ、含めなければより遅くなる。市場が落ち着く手数料は最小限のものになるはずだ。ノードがより高い手数料を要求すれば、そのノードはより低い手数料のすべてのトランザクションを見送ることになる。できるだけ多くの有料トランザクションを処理することで、より多くの取引量を扱い、おそらくより多くの収益を得られるだろう。この移行はシステムを管理する人間によって制御されるのではなく、個人が市場の力に自ら反応することによって行われる。

最終的には、ほとんどのノードは複数のGPUカードを持つ専門家によって運営されるかもしれない。今のところ、PCを持っている人なら誰でもビデオカードを気にせずに参加できるのは良いことで、しばらくそのままであることを願っている。最近はかなりまともなGPUを搭載したコンピュータが出荷されているので、後にそちらへ移行するかもしれない。

Bitcoinの重要な側面は、ネットワークのセキュリティがネットワークの規模と保護する必要がある価値の量とともに成長することだ。欠点は、まだ小さい初期段階では脆弱であることだが、盗まれる可能性のある価値は、盗むために必要な労力よりも常に小さいはずだ。誰かが何かを証明するために別の動機を持っているなら、それは私がすでに認めているポイントを証明しているだけだ。

コインの数と配布スケジュールの選択は、経験に基づく推測だった。ネットワークが稼働し始めたらそれに固定され、変更できないため、難しい選択だった。既存の通貨と同程度の価格になるようなものを選びたかったが、将来を知ることなくそれを行うのは非常に困難だ。結局、中間的なものを選んだ。Bitcoinが小さなニッチのままであれば、既存の通貨よりも単位あたりの価値は低くなる。世界の商取引のある割合に使用されることを想像すると、全世界で2,100万枚のコインしかないため、単位あたりの価値ははるかに高くなる。値は8桁の小数を持つ64ビット整数なので、1コインは内部的に100000000として表される。一般的な価格が小さくなっても十分な粒度がある。例えば、0.001が1ユーロに相当する場合、小数点の表示位置を変える方が簡単かもしれない。1 Bitcoinを持っていれば1000と表示され、0.001は1と表示される。

Rippleは、信頼を中央サーバーに集中させる以外のことを行う唯一の他のシステムであるという点で興味深い。

Satoshi

Satoshiさん、ありがとう。

昨日アプリを試してみた。Wine上でかなりうまく動いているようだ（MacOSで試したが、Linuxでも動くはずなので、来週仕事に戻ったら試してみる）。

右下隅にブロック数が表示されており、急速に増加してから止まる。これはグローバルチェーンの長さだろうか？それにしては進行が速すぎるように思える。それとも、試されたがパーシャルコリジョンに至らなかったジェネシスブロックの数だろうか？停止と開始の仕方が想定通りなのか、エミュレーション下での動作による不具合なのか分からない。私の推測では――グローバルチェーンの長さであり、最初の急速な進行は、ソフトウェアがチェーン内の先行ブロックをダウンロードし、有効であることを検証しているためだろう。

買い手/売り手の体験に関して、現在の設定ではグローバルチェーンは1時間あたり約6〜7ブロック進行すると理解している。0.1%が良いリスク率だと仮定すると、z=5となり、したがってどのトランザクションもチェーンに固定されるまで1時間弱待つ必要がある。ウェブコンテンツやバーチャルグッズなどのマイクロペイメントは、定義上低いオーバーヘッドが求められるものであり、1時間の待機はかなり大きなハードルのように思える。

ノードが協調なしにグローバルチェーンを進めるためのPoWを見つけようとすることは理解している。しかし次の文：

「CPUパワーの過半数が正直なノードによって制御されている場合、正直なチェーンが最も速く成長し、競合するチェーンを上回る。」

は私にとって混乱を招く。なぜなら、正直なチェーンが1つの攻撃CPUによって作業されるチェーンよりも速く成長できる唯一の方法は、パーシャルコリジョンを探すためにスキャンするキースペースが参加する正直なノード間で均等にシャーディングされている場合だけのように見えるからだ。そうすればコリジョンが見つかる速度はノード数に比例する。しかし、そのようなワークシャーディングの議論が見当たらない。これは明らかに複雑さを増す。同様に：

「ハードウェアの速度の増加とノード運営への関心の経時変化を補うために、プルーフ・オブ・ワークの難易度は1時間あたりの平均ブロック数を目標とする移動平均によって決定される。生成が速すぎる場合、難易度が上がる。」

各ブロックに必要な難易度は、ネットワークを通じてどのように伝達され、合意されるのだろうか？

重ねてありがとう。まだ質問があるが、1通のメールにはこれで十分だ :) いずれかの時点で、これらの議論をFAQ形式のドキュメントにまとめたいと思う。質問が些細に思えたら申し訳ない。

-mike

もう一つ明確でない点がある――グローバルチェーンは実際に処理すべき作業がある場合にのみ延長されるのだろうか？現在、ネットワークには数人しかいないにもかかわらず、常に成長しているようだ。つまり、空のブロックで延長されているのだろう。これは本当に必要なのだろうか？タイムスタンプは実時間と並行して行われる必要はないはずだ……単にイベントの順序を確立しているだけだ。

Mike Hearnは次のように書きました：

私の推測では――グローバルチェーンの長さであり、最初の急速な進行は、ソフトウェアがチェーン内の先行ブロックをダウンロードし、有効であることを検証しているためでしょう。

その通りだ。もっと明確な表現を考えているところで、「%d network blocks」や「%d block chain」のようなものを検討している。

0.1%が良いリスク率だと仮定すると、z=5となり、したがってどのトランザクションもチェーンに固定されるまで1時間弱待つ必要があります。ウェブコンテンツやバーチャルグッズなどのマイクロペイメントは、定義上低いオーバーヘッドが求められるものであり、1時間の待機はかなり大きなハードルのように思えます。

実際のリスクについては、0.1%に、買い手が巨大なコンピュータネットワークを持つ攻撃者である確率を掛けてくれ。

マイクロペイメントについては、支払いを即座に安全に受け入れることができる。支払い額が小さすぎて、それを盗む労力に見合わない。マイクロペイメントはほぼ常に知的財産に対するものであり、マーチャントに物理的な損失はない。マイクロペイメントを盗もうとする人は、おそらくいずれにせよ有料の顧客ではないだろうし、知的財産を盗みたいのであればファイル共有ネットワークを使える。

現在、企業は一定の貸し倒れ率を受け入れている。1回あるいは0回の確認ブロックでのリスクは、検証済みクレジットカード取引のチャージバック率よりもはるかに低いと考えている。

確認ブロックを待たないマーチャントに対する通常の詐欺は、マーチャントに支払いを送信し、マーチャントのコピーよりも先に二重支払いをネットワークに素早く伝播させようとすることだ。マーチャントができることは、自分のトランザクションをブロードキャストし、ネットワーク上で二重支払いのコピーを監視することだ。泥棒は監視期間中にブロードキャストできない。さもなければマーチャントのノードがコピーを受信してしまう。マーチャントはほとんどのネットワークノードが自分のバージョンを持ち、泥棒のバージョンが追いつけなくなるまで、1〜2分監視するだけで済む。わずか1〜2分の遅延で、支払いなしで済む確率を詐欺に値しないほど低くすることができる。泥棒は通常、それに見合うだけの高い確率で商品を無料で手に入れる必要がある。論文で議論されたブルートフォース攻撃に大量のCPUパワーを使用しても、上記の詐欺に加えて、泥棒の成功確率はあまり上がらない。

ダウンロードに時間がかかるもの、ウェブサイトへのアクセス、ウェブホスティング、サブスクリプションやサービスなど、何かへのアクセスを許可するものは、トランザクションが拒否された場合、数分後にキャンセルできる。

正直なチェーンが1つの攻撃CPUによって作業されるチェーンよりも速く成長できる唯一の方法は、パーシャルコリジョンを探すためにスキャンするキースペースが参加する正直なノード間で均等にシャーディングされている場合だけのように見えるからです。そうすればコリジョンが見つかる速度はノード数に比例します。しかし、そのようなワークシャーディングの議論が見当たりません。これは明らかに複雑さを増します。

キースペースは巨大で、2^256だ。ハッシュされるものにはノードの公開鍵とランダムなナンスが含まれるため、2つのノードが同じ空間で作業を重複させる可能性は無視できる。

各ブロックに必要な難易度は、ネットワークを通じてどのように伝達され、合意されるのですか？

伝達されない。計算式はプログラムにハードコードされており、すべてのノードが同じ計算を行って、次のブロックに必要な難易度を知る。誰かが計算式から逸脱した場合、そのブロックは多数派に受け入れられない。

重ねてありがとうございます。まだ質問がありますが、1通のメールにはこれで十分です :) いずれかの時点で、これらの議論をFAQ形式のドキュメントにまとめたいと思います。質問が些細に思えたら申し訳ありません。

問題ない。Mac Wineでテストしてくれてありがとう。

Satoshi

チェーンは常に延長され続ける。もし止まったら、攻撃者が追いつく時間を与えてしまう。空のブロックはそれほど大きくないので、心配いらない。

おっしゃる通り、重要なのはイベントの順序だ。

ああ、もちろん、それは根本的なことだ。お恥ずかしい。答えてくれてありがとう。初期バージョンのソフトウェアでは過度に明示的にすることを勧める。例えば「Global chain is currently %d blocks long」のようなものだ。

現時点での主な問題は、コインを生成しても、ダミーのトランザクションであっても、テストする相手がいないことだと思う。メーリングリストや、新しく鋳造したビットコインで何かできるような簡単なマーケットプレイスの計画はあるだろうか？

以前、物品の販売や注文の受付を容易にするマーケットプレイス機能の実装を始めたが、まだ半分しかできていない。eBayのようなものだが、オークションなしで「今すぐ購入」だけだ。とりわけ、誰でも簡単に通貨交換を提供できるようになる。

1PhUXucRd8FzQved2KGK3g1eKfTHPGjgFu に送金して、あなたのビットコインアドレス、または着信接続を受け入れられる場合はIPをメールで教えてくれれば、同額+50をお返しする。

Satoshiさん、こんにちは。

32.51コインを送った。私のビットコインアドレスは 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7rnj5n だ。

私のIPは現在 84.73.233.199 だが、ノートパソコンなので、このメールに対応される時にオンラインかどうかは分からない。ビットコインアドレスを使うことを勧める。間接送金でも同じコメント機能が使えると便利だ。コメントを受信者の公開鍵で暗号化してブロックに入れることはできるだろうか？

32.51と50.00を返送した。

間接送金にコメントを含める方法を何とか見つけたかったのだが、どうしても方法がなかった。BitcoinはEC-DSAを使用している。これは署名がRSAより桁違いに小さいため、現在の技術でブロックチェーンを実用的なサイズにするために不可欠だった。しかしEC-DSAはRSAのようにメッセージを暗号化することはできず、署名の検証にしか使用できない。

ありがとう。50を返送したので、これでおあいこだ。

なぜか、あなたからの送金は、アドレス帳に追加したにもかかわらず「From: unknown」と表示される。

トランザクションリストに「Generated (not accepted)」という行がある。コインの生成の試みが何かうまくいかなかったようだ。何が起きたのか分からない――おそらく私のノードがブロックの解決に成功したものの、ネットワークに送信される前にオフラインになったのだろうか？

トランザクションにメタデータを送信するには、他のメカニズムが必要になると思う。例えば、トランザクションに関連付けられた暗号化メッセージを（仮に）1ヶ月間ブロードキャストして保持し、ノードがメッセージに使用できるストレージ量にある種の予算を設けるといった方法だ。あるいは、受取人が自分にとって意味のある、しかし他の人には不透明な参照番号を生成し、支払人に渡すこともできる。この場合暗号化する必要がなく、ブロックに直接入れることができる。

50を受け取った。

ビットコインアドレスに送られたトランザクションは常に「from: unknown」と表示される。トランザクションは送信先しか示さない。ビットコインアドレスでの送金にはいくつかの問題があるが、相手がオンラインかどうかに関係なく誰にでも送金できるフォールバックオプションがあるのは非常に便利だ。将来的に改善を試みるアイデアがいくつかある。現時点では、現実世界のように取引の大多数がマーチャントとの間で行われるなら、マーチャントはほぼ常にIP受信の設定を行うだろう。P2Pファイル共有ネットワークは、ユーザーの大部分にファイアウォールのポートフォワーディング設定をさせることにかなり成功しているようだ。

「Generated (not accepted)」は通常、2つのノードがほぼ同時にブロックを発見した場合に発生し、そのうちの1つは受け入れられない。これは正常であり避けられない。v0.1.6でこれらを非表示にする予定だ。混乱を招き煩わしいだけで、ユーザーが見る必要はない。現在のようにネットワークがまだ小さい場合、着信接続を受信できないと、ブロックの通知を直接受信できないため、より不利になる。

はい、ほとんどのP2Pクライアントはルーターに自動的にポートを開かせるためにUPnPプロトコルを使用していると思う。これでリッスン率が大幅に向上するだろう。自分のルーターでDMZが有効になっていなかったことに気付いたが、有効だと思っていた。今は修正した。

新しいバージョンを知らせてもらう方法はあるだろうか？アプリは自動更新するのだろうか？繰り返しになるが、何らかのメーリングリストがあれば素晴らしい。

ここ数日、ウェブ向けの実用的なマイクロペイメント実装がどのように機能するかについて考えていた。重要な問題の一つは、マイクロペイメントを完全に自動化しつつ、ユーザーの口座を容易に使い果たすような悪用ができないようにすることだ。正しいアプローチは、EV SSL証明書を提示するウェブサイトがマイクロペイメントを自動的に要求できるようにし、課金が「低額」である限りブラウザがデフォルトで常に承認し、何が起きたかの小さな通知を表示することだと思う。サイトは、サイトデザインに合った任意の方法でコンテンツに支払いが必要であることを示せる。シンプルなガイドライン（例：リンクをクリックすると支払いが発生することを明確に示す、検索エンジンからの直接リンクで課金しない等）を満たさない悪質なサイトは、フィッシング対策フィルターと同様にSSL証明書をブラックリストに載せるだけだ。

プロトコルは非常にシンプルで、Firefoxの拡張機能やIEのBHOで実装できる。何らかの静的ファイル（例：protocol buffer）がサイトにホストされる。それは課金額、トランザクションの説明、ターゲットIP、およびトランザクションがターゲットノードに受け入れられた後にブラウザが読み込むURLを指定し、ユーザー識別子がURLパラメータで送信される。サイトはCookieとペイウォールコンテンツを返すことができる。プロセス全体は自動的で、例えばURLバーに小さなコインのアニメーションが表示されるだけだ。したがって、通常のウェブブラウジングと同様に便利だ。ユーザーのソフトウェアには、自動的に承認される支払いに何らかの制限がある。

このアプローチの主な問題は、誰かがユーザーインターフェースのガイドラインを決定し、ブラックリストによってそれを強制し、さらにどの支払い要件が自動承認に十分低いか、ユーザープロンプトが必要かを決定しなければならないことだ。これにより信頼された権威がシステムに再導入される。しかし、ユーザーがオープンマーケットで選択できるものだ。

ところで、もしノード間通信にまだprotocol buffersを使用していないのであれば、勧める。ここGoogleでは全てに使用しており、多くのバージョニングの問題をシンプルかつ効率的に解決する。

メーリングリストは以下の通りです：
bitcoin-list@lists.sourceforge.net
購読/解除ページ：
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
アーカイブ：
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

新しいバージョンは常にそこでアナウンスする。自動更新、または少なくとも新バージョンの通知は、確実に予定リストに入っている。将来的に、アップグレードするまで誰もあなたと通信したがらないような必要な変更が発生する可能性があり、古いバージョンのコードでそのことをユーザーに伝える必要がある。これは誰も信頼しないという文脈では、すべてがさらに難しくなる。

マイクロペイメントへのあなたのアプローチは正しいと思う。最初は、ユーザーが慣れて自動設定にする準備ができるまで、デフォルトで許可を求める方が良いかもしれない。しかし最終目標は、あなたが描くような、携帯電話の1分あたりの料金をあまり考えずに使うのと同様のものになるべきだ。

昨年Google protocol buffersがリリースされた時に調べたが、その時にはすべてをすでに書き終えていた。私がやったのはBoost Serialisationに似たものだった。このアプリケーションでは、プロトコルをハッキングする極めて大きなインセンティブを持つ見知らぬ人からのメッセージを解析していたため、すべてのコードの行を這うようにチェックして気密性を確信できるよう、できるだけ基本的なものにする必要があった。バイナリ形式における不要な自由度が、攻撃の潜在的な角度を倍増させることが明らかになった。しかし、社内でprotocol buffersを標準化したのは本当に正しいことだ。一般的なケースでは最適なソリューションだと思う。