「Bitcoin P2P e-cash paper」— サトシのビットコイン初公開(2008-10)
完全にP2Pで動作する、信頼された第三者を必要としない新しい電子キャッシュシステムに取り組んでいる。
論文はこちらで公開している:
http://www.bitcoin.org/bitcoin.pdf
主な特性:
- 二重支払いはP2Pネットワークによって防止される。
- 造幣局や信頼された第三者は不要。
- 参加者は匿名でいられる。
- 新しいコインはHashcash形式のプルーフ・オブ・ワークから生成される。
- 新しいコイン生成のためのプルーフ・オブ・ワークが、二重支払いを防ぐためのネットワークの動力ともなる。
ビットコイン:ピアツーピア電子キャッシュシステム
概要:完全なピアツーピア版の電子キャッシュは、金融機関を経由する負担なしに、オンライン決済を当事者間で直接送金することを可能にする。デジタル署名はソリューションの一部を提供するが、信頼できる第三者が二重支払いの防止に依然として必要であれば、主要な利点は失われる。我々は、ピアツーピアネットワークを用いた二重支払い問題の解決策を提案する。ネットワークは、トランザクションをハッシュベースのプルーフ・オブ・ワークの継続的なチェーンにハッシュ化することでタイムスタンプを付与し、プルーフ・オブ・ワークをやり直さない限り変更できない記録を形成する。最長のチェーンは、目撃されたイベントの順序の証明としてだけでなく、それが最大のCPUパワーのプールから生まれたことの証明としても機能する。正直なノードがネットワーク上で最も多くのCPUパワーを支配している限り、最長のチェーンを生成し、いかなる攻撃者も凌駕できる。ネットワーク自体は最小限の構造しか必要としない。メッセージはベストエフォートベースでブロードキャストされ、ノードは自由にネットワークを離脱・再参加でき、不在中に何が起きたかの証明として最長のプルーフ・オブ・ワークチェーンを受け入れる。
完全な論文はこちら:
http://www.bitcoin.org/bitcoin.pdf
サトシ・ナカモト
完全にP2Pで動作する、信頼された第三者を必要としない新しい電子キャッシュシステムに取り組んでいる。
論文はこちらで公開している:
http://www.bitcoin.org/bitcoin.pdf
こうしたシステムは、ぜひとも、ぜひとも必要だ。だが、あなたの提案を私が理解する限り、この方式では必要な規模にスケールしないように見える。
譲渡可能なプルーフ・オブ・ワークトークンに価値を持たせるには、貨幣的価値がなければならない。貨幣的価値を持つには、非常に大きなネットワーク内で——例えばbittorrentに類似したファイル交換ネットワークのように——移転されなければならない。
二重支払いイベントをタイムリーに検出し拒否するためには、トランザクション内のコインの過去のトランザクションの大部分を持っていなければならないが、素朴に実装すると、各ピアが過去のトランザクションの大部分、あるいは最近発生した過去のトランザクションの大部分を持つ必要がある。何億人もの人々がトランザクションを行っている場合、それは膨大な帯域幅となる——すべてのノードがすべて、またはその大部分を知らなければならない。
こうしたシステムは、ぜひとも、ぜひとも必要だ。だが、あなたの提案を私が理解する限り、この方式では必要な規模にスケールしないように見える。
譲渡可能なプルーフ・オブ・ワークトークンに価値を持たせるには、貨幣的価値がなければならない。貨幣的価値を持つには、非常に大きなネットワーク内で——例えばbittorrentに類似したファイル交換ネットワークのように——移転されなければならない。
二重支払いイベントをタイムリーに検出し拒否するためには、トランザクション内のコインの過去のトランザクションの大部分を持っていなければならないが、素朴に実装すると、各ピアが過去のトランザクションの大部分、あるいは最近発生した過去のトランザクションの大部分を持つ必要がある。何億人もの人々がトランザクションを行っている場合、それは膨大な帯域幅となる——すべてのノードがすべて、またはその大部分を知らなければならない。
ネットワークがそこまで大きくなるずっと前から、利用者は簡易支払い検証(論文の第8節)を使って二重支払いを確かめれば、安全に使えるようになる。必要なのはブロックヘッダーのチェーンだけで、1日に約12KBで済む。新しいコインを作成しようとする人だけがネットワークノードを実行する必要がある。当初はほとんどのユーザーがネットワークノードを実行するが、ネットワークがある程度以上に成長すると、専用ハードウェアのサーバーファームを持つ専門家にますます委ねられることになる。サーバーファームはネットワーク上に1つのノードを持つだけでよく、LANの残りはそのノードに接続する。
帯域幅は、あなたが思うほど法外なものではないかもしれない。典型的なトランザクションは約400バイトだ(ECCはうまくコンパクトだ)。各トランザクションは2回ブロードキャストされる必要があるので、1トランザクションあたり1KBとしよう。Visaは2008会計年度に370億件のトランザクションを処理した。これは1日平均1億件のトランザクションだ。それだけのトランザクションには100GBの帯域幅、つまりDVD12枚分かHD画質の映画2本分、現在の価格で約18ドル相当の帯域幅が必要となる。
ネットワークがそこまで大きくなるには数年かかるだろうし、その頃にはインターネットでHD映画2本分を送ることは大したことではないだろう。
Satoshi Nakamoto
正直なノードがネットワーク上で最も多くのCPUパワーを支配している限り、 最長のチェーンを生成し、いかなる攻撃者も凌駕できる。
しかし実際にはそうなっていない。悪者は日常的に10万台以上のマシンのゾンビファームを支配している。スパム送信ゾンビのブラックリストを運用している私の知人は、1日に100万もの新しいゾンビを目にすることが珍しくないと言う。
これはhashcashが今日のインターネットで機能しないのと同じ理由だ——善人は悪者よりはるかに少ない計算能力しか持っていない。
他の点についても疑問はあるが、これが致命的な問題だ。
R’s, John
SNサトシ・ナカモトの投稿(2008年10月31日18:10 UTC)正直なノードがネットワーク上で最も多くのCPUパワーを支配している限り、 最長のチェーンを生成し、いかなる攻撃者も凌駕できる。
しかし実際にはそうなっていない。悪者は日常的に10万台以上のマシンのゾンビファームを支配している。スパム送信ゾンビのブラックリストを運用している私の知人は、1日に100万もの新しいゾンビを目にすることが珍しくないと言う。
これはhashcashが今日のインターネットで機能しないのと同じ理由だ—— 善人は悪者よりはるかに少ない計算能力しか持っていない。
その点を指摘してくれてありがとう。
私はその主張を十分に強く表現できていなかった。必要なのは、善意の者たちが合わせて、どの攻撃者一人よりも多くのCPUパワーを持つことだ。
ネットワークを圧倒するには小さすぎる多くの小規模ゾンビファームが存在し、それらはビットコインを生成することで利益を得ることができる。小規模ファームが「正直なノード」となる。(「正直」より良い用語が必要だ。)より多くの小規模ファームがビットコイン生成に向かうほど、ネットワークを圧倒するためのハードルは上がり、より大きなファームも圧倒するには小さすぎることになり、それらもビットコインを生成した方が良いことになる。「ロングテール」理論によれば、小規模、中規模、そして単に大規模なファームを合わせれば、最大のゾンビファームよりもはるかに多くなるはずだ。
たとえ悪人がネットワークを圧倒しても、一瞬で金持ちになれるわけではない。できるのは、自分で払った金を取り戻すことだけだ。小切手を不渡りにするようなものだ。これを悪用するには、商人から何かを購入し、発送されるまで待ち、それからネットワークを圧倒してお金を取り戻そうとする必要がある。そのようなカーディング詐欺を試みるよりも、ビットコインを生成する方が多くの利益を得られると思う。そのような巨大なゾンビファームがあれば、他の全員を合わせたよりも多くのビットコインを生成できるだろう。
ビットコインネットワークは、ゾンビファームをビットコイン生成に転向させることで、実際にスパムを減らすかもしれない。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
SNサトシ・ナカモトの投稿(2008年11月3日01:37 UTC)二重支払いイベントをタイムリーに検出し拒否するためには、トランザクション内のコインの過去のトランザクションの大部分を持っていなければならないが、素朴に実装すると、各ピアが過去のトランザクションの大部分、あるいは最近発生した過去のトランザクションの大部分を持つ必要がある。何億人もの人々がトランザクションを行っている場合、それは膨大な帯域幅となる——すべてのノードがすべて、またはその大部分を知らなければならない。
ネットワークがそこまで大きくなるずっと前から、利用者は簡易支払い検証(論文の第8節)を使って二重支払いを確かめれば、安全に使えるようになる。必要なのはブロックヘッダーのチェーンだけだ。
Simplified Payment Verificationについて私の理解が正しければ:
新規コイン発行者はすべてのコインと最近のコイン送金を保存する必要がある。新規コイン発行者は多数存在し、発行者になりたい者は誰でもなれるが、コイン利用者の方がはるかに多い。
一般の主体は単にコインを送金する。コイン送金が有効か確認するには、それを1つ以上の新規コイン発行者に報告し、その新規コイン発行者が受け入れるかを見る。新規コイン発行者は古いコインの送金を検査して新しいコインが有効な形式を持つようにし、その検査結果を公開して、人々が送金をその新規コイン発行者に報告するよう促す。
誰かがコインを二重支払いし、片方の支出が一方の新規コイン発行者に、もう片方が同時に別の新規コイン発行者に報告された場合、両発行者は支払いの一意の順序について速やかに合意する必要がある。これは大規模分散データベースの非自明な問題であり、ピアツーピア解は現時点で存在しない悪名高く厄介な問題だ。明らかに解ける問題で、人々は常にこれを解いているが、簡単ではない。失敗することも頻繁にある。
しかし、コイン発行ネットワークは少数の発行者に支配されると想定しよう。実際そうなる可能性が高い。
少数の主体が新規コインを発行するなら、これは単一発行者の場合より国家攻撃に対する耐性が高い。だが政府は金融ネットワークを定期的に攻撃しており、最近の攻撃に起因する金融崩壊は今この瞬間も進行中だ。
政府支援企業が業界に参入し、やがて悪行が義務化され、悪の金融ネットワークが誠実な金融ネットワークより大きくなる。何が起きているかみんなが知っていても、ネットワーク効果のために人々は悪の金融ネットワークが発行する紙幣を使い続ける —— ビジネスをしたいなら、主要な大きな発行者を使うからだ。
すると知識ある人々は、悪の金融ネットワークが破綻に向かっている、政府支援企業が「金融システム全体の崩壊」を引き起こすところだと不満を述べる。これは2005年にウォリソンとアラン・グリーンスパンが訴えたのと同じだ。政府は悪の政府支援企業を縮小すべきか議論する。例えば「S. 190 [109th]: Federal Housing Enterprise Regulatory Reform Act of 2005」のように。だが彼らはeasy moneyが魅力的すぎることに気付き、S. 190は政治活動家の群れの前に派手に葬られる。彼らはeasy moneyは健全であり、それに反対するのは人種差別主義者・ナチ・無知・憎悪に満ちていると唱えるのだ。政府支援企業の不良住宅ローン債券発行ポートフォリオ制限を議論した最近のS. 190論争は、1790年代の新規アシニア発行制限論争の完全な再現である。
貨幣に対する大きく簡単な政府攻撃は、フランスのアシニア(1792年)など、近代政治攻撃の最初のものと同様、単一の中央貨幣発行者を標的とする。だが19世紀後半には金融ネットワーク自体への政治攻撃が始まった。例えば1913年の連邦準備法だ。目標は常にネットワークを単一のtoo big to failエンティティにまとめ上げることであり、これらの攻撃は最近のものに見られるように、徐々に大規模化・深刻化・破滅化している。各攻撃は大成功を収め、攻撃が引き起こす大災害の後、攻撃者は貧者・抑圧者・国家全般の救世主と称えられ、その結果生じる悪い影響の責任はユダヤ人・強欲な銀行家・投機家などに転嫁される。そのような攻撃は普通の人には理解しがたいからだ。あなたの提案は理解しがたい —— 普通のユーザーは政府支援のセキュリティアップデートで簡単にだまされるだろう。さらに危機が訪れた時、当局者が正しいことを疑い、問題は悪の投機家であるという論調に異論を唱えることは、2007年のアメリカで起きたように政治的自殺になり、ワイマール・ドイツのように物理的な自殺になることもある。
それでも、これまで私が見たどんなものよりも優れており、政府支援企業による攻撃への耐性も高い。
SNサトシ・ナカモトVisaは2008年度に370億トランザクションを処理した。1日平均1億件だ。その量のトランザクションは100GBの帯域、つまりDVD 12枚またはHD映画2本分の サイズ、現在の価格で約18ドルの帯域に相当する。
ネットワークがそこまで大きくなるには数年かかるだろうし、その頃にはインターネットでHD映画2本分を送ることは大したことではないだろう。
政府の攻撃時までに百や千の貨幣発行者がいれば、最近見た種類の金融ネットワークに対する政府攻撃はずっと難しくなるだろう。
だが貨幣発行者に必要なデータ量と帯域を最小化することに我々は注意を向ける必要があると思う —— 小さなコインに対してこのプロトコルは無駄が多いように見える。大きなコインに対しては完全プロトコルを使い、小さなコインに対しては何らかの短縮版で、人々は大きなコインにまとめられるまでは少額にアカウント型貨幣を信頼する、というのが理想的だろう。
貨幣発行者が必要とするデータストレージと帯域が小さいほど、最近見た種類の金融ネットワークに対する政府攻撃に対するシステムの耐性は高い。
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
Simplified Payment Verificationについて私の理解が正しければ:
新規コイン発行者はすべてのコインと最近のコイン送金を 保存する必要がある。
新規コイン発行者は多数存在し、発行者になりたい者は誰でも なれるが、コイン利用者の方がはるかに多い。
一般の主体は単にコインを送金する。コイン送金が有効か確認 するには、それを1つ以上の新規コイン発行者に報告し、その 新規コイン発行者が受け入れるかを見る。新規コイン発行者は 古いコインの送金を検査して新しいコインが有効な形式を持つ ようにし、その検査結果を公開して、人々が送金をその新規 コイン発行者に報告するよう促す。
このシステムの本当の問題は、ビットコインの市場だと思う。
プルーフ・オブ・ワークの計算に、本質的な価値はない。供給曲線を限ることはできる(コンピューターが毎年速くなる分、この「通貨」は年に35%ほどインフレするが)。だが、正の価格でそれと交わる需要曲線がない。
同じこと(本源的価値の欠如)は法定通貨にも言える、と私は知っている。しかし法定通貨に対する人工的な需要は、課税や法定通貨法など(の制度)によって作り出されている。また、法定通貨であっても、他の法定通貨のより高いインフレ率に対するインフレ・ヘッジになりうる。だがビットコインの場合、35%のインフレ率は技術がほぼ約束してしまう。課税の裏付けも、法貨の法律もない。避けられるなら、こんな高インフレの通貨で資産を持つ者はいない。
Bear
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
[武力行使による独占に対するシステムの脆弱性に関する 長い解説は省略。]
政治的問題の解決策を暗号学に求めても見つからないだろう。
確かにそうだが、軍拡競争の大きな戦いには勝てるし、数年間は自由の新しい領域を手にできる。
政府は、Napsterのように中央で管理されるネットワークの首を切るのは得意だ。だが、GnutellaやTorのような純粋なP2Pネットワークは、持ちこたえているように見える。
Satoshi
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
本日のメーリングリストのモデレーターのお達し:
暗号によるお金のプロトコルの議論を、お金の政治の議論へ枝分かれさせたがっている人が大勢いるようだ。私自身も狂信的なリバタリアンだが、ここは狂信的なリバタリアンのメーリングリストではない。プロトコルそのものか、その直接の実用性の議論にとどめてほしい。不換紙幣の危うさ、税金、ミルドレッドおばさんの金貨のコレクション、等々の話はしないでほしい。
Perry
暗号学メーリングリスト 購読をやめるには、「unsubscribe cryptography」と書いたメールをmajordomo@metzdowd.comへ送ってください
ビットコインはすごく有望なアイデアだと思うんだ。正直な参加者のCPUパワーが攻撃者を上回る、という前提にセキュリティを置く考え方が気に入っているんだ。ロングテールの力を活用した、実に現代的な考え方だ。Wikipediaが始まった時、うまくいくとは思わなかったけど、同じような理由で大成功を収めた。
また、偽造できなくて、生産ペースが予測できて、腐敗した者たちに左右されないトークン――これには、価値が生まれる見込みがあると思うんだ。法定通貨よりもゴールドに近い。ニック・サボが何年も前に「ビットゴールド」[1]と呼んでいたものがあるけど、これはその構想の実装になりうるよ。重量級の非匿名システムの上に軽量な匿名決済スキームを構築する提案もあり、ビットコインを活用すれば、論文で述べられた仕組みを超える匿名性も実現できるだろう。
ただ残念ながら、このシステムを完全に理解するのに苦労しているんだ。論文は鍵となる概念といくつかのデータ構造を説明しているけど、システムの参加者が従わなければならないさまざまな規則や検証をはっきりとは定めていない。
特に分からないのは、P2Pのノードがほかのノードから新しいブロックを受け取ったとき、正確にどんな検証をするのか、そしてブロードキャストされてきたトランザクションをどう扱うのかだ。たとえば、ブロードキャストされたトランザクションがすべてのノードに届かなくても、じきにブロックチェーンに入るから問題ない、と書かれている。それはどうやって起きるんだろう。「次の」ブロックを作るノード(最初にHashcashの衝突を見つけたノード)がそのトランザクションを聞いていなくて、さらにそのトランザクションを聞いていないノードがいくつかブロックを足したら? そのトランザクションを聞いたノードはみんな、次の衝突を見つける幸運に恵まれたらブロックに入れようと、それを持ち続けるのかな。
あるいは、たとえばノードがどのチェーンが一番速く伸びるかを見守るあいだ二つ以上のチェーンを保持していて、チェーンAに、チェーンBにあるコインの二重支払いを含むブロックが届いたら? それはチェックされるのかな、されないのかな。(誰かが二重支払いをして、ノードの二つの集団が、同じコインを使った別々のトランザクションをそれぞれ聞いた場合に起こりうる。)
こうしたデータの管理や、飛び交うパケットをすべて扱うための規則が、論文にはほとんど書かれていない。
それから、正直な参加者全員を上回る計算能力を集められる優勢な攻撃者が、二重支払いやトランザクションの取り消しをどうやって実現するのかも、正確には分からない。新しいブロックを作って足し、最長のチェーンを作れるのは分かる。でも、チェーンの中の古いトランザクションをどうやって消したり足したりできるんだろう。攻撃者が新しいブロックを送り出すとき、何も消されていないことを確かめるために、正直なノードができる整合性のチェックはないのかな。この攻撃をもっと説明してもらえると、攻撃者がこれで得るものと、その計算能力を使って正直に新しいコインを発行する場合とを比べて判断するのに役立つだろう。
支払いのトランザクションについては、コインの受け取り手はどんなチェックをしなければならないのかな? コインの移転の履歴をすべてさかのぼって、リストのすべてのトランザクションが「タイムスタンプ」のブロックチェーンに本当につながっているかを確かめる必要があるのかな。それとも最新の一つだけでいいのかな。タイムスタンプのノードはトランザクションをチェックして、コインの前のトランザクションがチェーンにあることを確かめ、チェーンにあるトランザクションはすべて有効なコインを表すという規則を守らせるのかな。
質問ばかりですまない。でも、さっきも言ったように、これは本当に有望で独創的なアイデアに思えるし、この考えがこれからどう発展していくのかを楽しみにしている。アイデアを、もっと処理の流れに沿って説明したものがあると助かる。さまざまなオブジェクト(コイン、ブロック、トランザクション)のデータ構造、メッセージに含まれるデータ、そしてこのシステムで起こるさまざまな出来事を扱う手順のアルゴリズムを、具体的に書いたものだ。実装に取り組んでいると書いていたけど、次の一歩としては、システムのもっと形式的な、文章による説明が役に立つと思う。
ハル・フィニー
[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html
コンピューターが毎年速くなる分、この「通貨」は年に35%ほどインフレする …35%のインフレ率は技術がほぼ約束してしまう
ハードウェアの高速化には、手を打ってある。「ハードウェアが速くなることと、ノードを動かす人の関心が時とともに変わることを補うため、プルーフ・オブ・ワークの難易度は、1時間あたりの平均ブロック数を目標にした移動平均で決まる。生成が速すぎれば、難易度が上がる」。
コンピューターが速くなり、ビットコインを作るのに注がれる計算力の総量が増えれば、難易度もそれに比例して上がり、新しく生まれる量の合計は一定に保たれる。したがって、将来毎年どれだけの新しいビットコインが生成されるかは事前にわかっている。
新しいコインが生産されることは通貨供給量が計画的に増加することを意味するが、必ずしもインフレになるわけではない。通貨供給量の増加が利用者数の増加と同じ率で増加すれば、物価は安定する。需要ほど速く増加しなければ、デフレが起こり、通貨の初期保有者はその価値の上昇を目にすることになる。
コインは、最初に何らかの形で配る必要がある。一定の割合で配るのが、一番よい方式に思える。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
ブロードキャストされたトランザクションがすべてのノードに届かなくても、じきにブロックチェーンに入るから問題ない、と書かれている。それはどうやって起きるんだろう。「次の」ブロックを作るノード(最初にHashcashの衝突を見つけたノード)がそのトランザクションを聞いていなくて、さらにそのトランザクションを聞いていないノードがいくつかブロックを足したら? そのトランザクションを聞いたノードはみんな、次の衝突を見つける幸運に恵まれたらブロックに入れようと、それを持ち続けるのかな。
その通り、ノードはトランザクションをブロックに入るまでワーキングセットに保持する。トランザクションがノードの90%に到達した場合、新しいブロックが見つかるたびに、そのブロックに含まれる確率は90%だ。
HFハル・フィニーあるいは、たとえばノードがどのチェーンが一番速く伸びるかを見守るあいだ二つ以上のチェーンを保持していて、チェーンAに、チェーンBにあるコインの二重支払いを含むブロックが届いたら? それはチェックされるのかな、されないのかな。(誰かが二重支払いをして、ノードの二つの集団が、同じコインを使った別々のトランザクションをそれぞれ聞いた場合に起こりうる。)
それをチェックする必要はない。先行する分岐のトランザクションが有効となり、もう一方は無効となる。誰かがそのような二重支払いを試みた場合、1つのみの支払いが常に有効となり、他は無効となる。
トランザクションの受取人は通常、この種の可能性が解決されるまでの時間を確保するため、おそらく1時間以上トランザクションを保持する必要がある。コインは即座に再度使うことができるが、商品の発送などの行為を行う前には待つべきだ。
HFハル・フィニーそれから、正直な参加者全員を上回る計算能力を集められる優勢な攻撃者が、二重支払いやトランザクションの取り消しをどうやって実現するのかも、正確には分からない。新しいブロックを作って足し、最長のチェーンを作れるのは分かる。でも、チェーンの中の古いトランザクションをどうやって消したり足したりできるんだろう。攻撃者が新しいブロックを送り出すとき、何も消されていないことを確かめるために、正直なノードができる整合性のチェックはないのかな。この攻撃をもっと説明してもらえると、攻撃者がこれで得るものと、その計算能力を使って正直に新しいコインを発行する場合とを比べて判断するのに役立つだろう。
攻撃者は末尾にブロックを追加するのではない。自分のトランザクションが含まれるブロックまで遡り、そのブロックとその後のすべてのブロックをやり直さなければならない。さらに、その作業中にネットワークが末尾に追加し続けるすべての新しいブロックもやり直す必要がある。歴史を書き換えているのだ。その分岐がより長くなれば、それが新しい有効なチェーンとなる。
これは重要なポイントに触れている。たとえその場にいる全員が不正を目にしていたとしても、その事実を利用する方法はない。
最長のチェーンが常に有効なものと見なされることは絶対に必要だ。その場にいたノードは、ある分岐が先にあり別の分岐に置き換えられたことを覚えているかもしれないが、その場にいなかった者にこのことを納得させる方法はない。ある分岐が最初だったと主張する派閥、別の分岐が最初だったと見た派閥、そして後から参加して何が起きたか見ていない派閥——このような分裂は許されない。CPUパワーによるプルーフ・オブ・ワークの投票が、最後に決めなければならない。全員が同じ認識に立ち続ける方法は一つしかない。何があっても、最長のチェーンを常に正当とみなすことだ。
HFハル・フィニー支払いのトランザクションについては、コインの受け取り手はどんなチェックをしなければならないのかな? コインの移転の履歴をすべてさかのぼって、リストのすべてのトランザクションが「タイムスタンプ」のブロックチェーンに本当につながっているかを確かめる必要があるのかな。それとも最新の一つだけでいいのかな。
受取人はブロックチェーン内の十分な深さまで遡って検証するだけでよく、多くの場合2トランザクションの深さだけで十分だ。それ以前のすべてのトランザクションは破棄できる。
HFハル・フィニータイムスタンプのノードはトランザクションをチェックして、コインの前のトランザクションがチェーンにあることを確かめ、チェーンにあるトランザクションはすべて有効なコインを表すという規則を守らせるのかな。
その通り、まさにそうだ。ノードはブロックを受信すると、その中のすべてのトランザクションの署名を以前のブロック内のトランザクションと照合してチェックする。ブロックは前のブロックまたは同一ブロック内の有効なトランザクションに依存するトランザクションのみを含むことができる。トランザクションCは同一ブロック内のトランザクションBに依存し、Bはより前のブロック内のトランザクションAに依存することができる。
HFハル・フィニー質問ばかりですまない。でも、さっきも言ったように、これは本当に有望で独創的なアイデアに思えるし、この考えがこれからどう発展していくのかを楽しみにしている。アイデアを、もっと処理の流れに沿って説明したものがあると助かる。さまざまなオブジェクト(コイン、ブロック、トランザクション)のデータ構造、メッセージに含まれるデータ、そしてこのシステムで起こるさまざまな出来事を扱う手順のアルゴリズムを、具体的に書いたものだ。実装に取り組んでいると書いていたけど、次の一歩としては、システムのもっと形式的な、文章による説明が役に立つと思う。
質問してくれてありがたい。実際、逆のやり方をした。すべての問題を解決できると自分で納得するには、まずコードを全部書かなければならなかった。それから論文を書いた。詳細な仕様を書くよりも先にコードをリリースできると思う。ハルが空白を埋めた仮定のほとんどは、すでに正しい。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
核心的なコンセプトは、多数のエンティティが誰がどのビットコインを 所有しているかについて完全で一貫した情報を保持するということだ。
しかし、一貫性を維持するのは厄介である。誰かがあるトランザクションを あるメンテナーに報告し、別の誰かが別のトランザクションを別の メンテナーに伝えた場合に何が起こるかが明確でない。トランザクションは 過去のすべてのトランザクションのグローバルに共有されたビューに 組み込まれるまで有効であることがわからず、過去のすべてのトランザクションの グローバルに共有されたビューがグローバルに共有されていることは、 ある程度の時間が経過し、多くの新しいトランザクションが到着した後に しかわからない。
これをどのように行うか説明していたのに私が理解できなかったのか、 それともできると確信していたが詳細については少し曖昧だったのか?
プルーフ・オブ・ワークチェーンが同期化問題の解決策であり、誰も信頼することなくグローバルに共有されたビューが何であるかを知る方法だ。
トランザクションはネットワーク全体に素早く伝播するため、同じトランザクションの2つのバージョンがほぼ同時に報告された場合、先にスタートした方がより多くのノードに最初に到達するという大きな優位性を持つ。ノードは最初に見たものだけを受け入れ、2番目に到着したものを拒否するため、より早いトランザクションの方がより多くのノードによって次のプルーフ・オブ・ワークへの組み込みに取り組まれる。実質的に、各ノードはどのトランザクションを最初に見たかについての見解を、プルーフ・オブ・ワークの作業にそれを含めることで投票している。
トランザクションがまったく同時に届き、均等に分割された場合は、どちらが先にプルーフ・オブ・ワークに入るかに基づく運の問題であり、それが有効なものを決定する。
ノードがプルーフ・オブ・ワークを発見すると、新しいブロックはネットワーク全体に伝播し、全員がそれをチェーンに追加して次のブロックの作業を開始する。もう一方のトランザクションを持っていたノードは、受け入れられたチェーンに基づきそれが無効となったため、ブロックへの組み込みを試みるのを中止する。
プルーフ・オブ・ワークチェーン自体が、グローバルに共有されたビューから生まれたことの自明な証拠だ。ネットワークの過半数だけが、このような困難なプルーフ・オブ・ワークのチェーンを生成するのに十分なCPUパワーを共同で持っている。ユーザーはプルーフ・オブ・ワークチェーンを受信すると、ネットワークの過半数が何を承認したかがわかる。トランザクションがチェーン内の数リンク前のリンクにハッシュされると、それはグローバルな履歴に確固として刻み込まれる。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
帯域幅は、あなたが思うほど法外なものではないかもしれない。典型的なトランザクションは約400バイトだ(ECCはうまくコンパクトだ)。各トランザクションは2回ブロードキャストされる必要があるので、1トランザクションあたり1KBとしよう。Visaは2008会計年度に370億件のトランザクションを処理した。これは1日平均1億件のトランザクションだ。それだけのトランザクションには100GBの帯域幅、つまりDVD12枚分かHD画質の映画2本分、現在の価格で約18ドル相当の帯域幅が必要となる。
問題は、既存の銀行カード網と比較している点だ。
だが新しい通貨が古い通貨と正面から競うことはできない。ネットワーク効果が古い側に味方するからだ。
既存のカード網が手を出さない領域へ行くしかない。
いまファイル共有はビットの物々交換で成り立っているが、これには欲求の二重の一致が要る。人々は自分がダウンロードしているファイルしかアップロードせず、ダウンロードが終わればシードをやめる。だから出回るのは、同時に多くの人が欲しがる活発なファイルだけだ。
ファイル共有には極めて安価なトランザクションが要る。クライアントあたり毎秒数件、来る日も来る日もで、月あたりの取引コストはクライアントあたりごく僅かでなければならない。だからビットコインの上でファイル共有を支えるには、ビットコインの上に口座マネーの層を重ね、最小コインの十万分の一規模のトランザクションを扱えるようにし、匿名性のためにはさらにその上にチャウム式の電子マネーを重ねる必要がある。
ビットコイン銀行をbinkと呼ぼう。ビットコインは口座マネーに対して、金本位制時代の金と同じ関係に立つ。binkどうしは、最も流動性が必要なときに相手が流動的でいる保証を互いに信用しないので、十万秒に一度ほどビットコインを動かして純差額を決済する。だからビットコインの持ち主はそう頻繁には替わらない。ほとんどの取引は口座のレベルで相殺される。binkが互いにビットコインを要求するのは、口座マネーを長く抱えたくないからにすぎない。こうして、少量のビットコインを稀に動かすだけで、それより多くの口座マネーを頻繁に取引させることができる。
では、あるノードがプルーフ・オブ・ワークに 正直で正当な単一支払いのトランザクション群を組み込み、 別のノードがプルーフ・オブ・ワークに 同様に正直で正当な単一支払いの 別のトランザクション群を組み込み、 両方のプルーフがほぼ同時に 生成されたとする。
そのときはどうなる?
両方ともブロックをブロードキャストする。すべてのノードは両方を受信して保持するが、最初に受信した方にのみ取り組む。正確に半分が一方を先に受信し、残りの半分がもう一方を先に受信したとしよう。
短時間で、すべてのトランザクションは伝播を完了し、全員がフルセットを持つことになる。各側で作業しているノードは、自分の分岐に欠けているトランザクションの追加を試みる。次のプルーフ・オブ・ワークが発見されると、そのノードが取り組んでいた前のブロックの分岐がより長くなり、同点が解消される。どちらであっても、新しいブロックにはトランザクションのもう半分が含まれるため、いずれの場合でも分岐にはすべてのトランザクションが含まれることになる。分岐が2回連続で起こるという起こりにくいイベントの場合でも、2回目の分岐の両側にはいずれにせよフルセットのトランザクションが含まれる。
トランザクションがブロックに入るまで1回かそれ以上の追加サイクルを待つ必要があっても問題ではない。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
さらに言えば、このシステムは機能させられない。提案されたシステムでは、誰がどのコインを持っているかを追跡する作業がシニョリッジで賄われ、それにはインフレが要るからだ。
インフレの問題で困っているなら、代わりに取引手数料で賄うように変えるのは簡単だ。やり方はこれだけだ。どの取引も、出力の額を入力の額より1セント少なくすればいい。クライアントソフトウェアが意図した支払い額より1セント多くトランザクションを自動的に書くか、受取人側から差し引くことができる。ノードがブロックのプルーフ・オブ・ワークを見つけた時のインセンティブ値は、ブロック内の手数料の合計になる。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
では、競争に負けたコインはどうなるのか?
…2番目に来た人がコインを失う可能性が高いのは 少し厳しい。
同じトランザクションの複数の二重支払いバージョンがある場合、1つだけが有効となる。
支払いの受取人は、それが有効であると信じる前に1時間ほど待たなければならない。ネットワークはそれまでにあらゆる二重支払いの競争を解決する。
無効となった二重支払いを受け取った人は、そもそもそれを持っていたとは思っていなかった。その人のソフトウェアではトランザクションが「未確認」から「無効」に変わったと表示されていたであろう。必要に応じて、UIはトランザクションがブロックチェーン内で十分に深くなるまで非表示にすることもできる。
JAジェームズ・A・ドナルドさらに、あなたの事象の記述は、タイミングとコイン生成に 制約があることを示唆している——ネットワーク全体が 新しいコインのニュースがネットワーク全体に広まるのに 必要な時間と比較して、ゆっくりとコインを生成するということだ
それを明確にできなかったならすまない。ブロック間の目標時間はおそらく10分になるだろう。
すべてのブロックには作成時刻が含まれる。時刻が36時間以上ずれている場合、他のノードはそのブロックに取り組まない。直近の6*24*30ブロックの期間が15日未満の場合、ブロックの生成が速すぎるため、プルーフ・オブ・ワークの難易度が倍になる。全員が同じチェーンデータで同じ計算を行うため、チェーン内の同じリンクで全員が同じ結果を得る。
JAジェームズ・A・ドナルド我々は支払い者に、分岐の競争が解決される 時間ではなく、支払いがネットワーク全体に広がる 時間において、トランザクションが有効であることの 確信を持たせたい。
即時の取り消し不能性は機能ではないが、既存のシステムよりはるかに高速だ。紙の小切手は1〜2週間後に不渡りになることがある。クレジットカードのトランザクションは60〜180日後まで異議を申し立てられる。ビットコインのトランザクションは1〜2時間で十分に不可逆的となりうる。
JAジェームズ・A・ドナルドあるノードが自分に関係のないすべての支払いを 無視している場合、そのノードには何の不利な結果もない。
私が最近投稿したトランザクション手数料ベースのインセンティブシステムにより、ノードは受信したすべての有料トランザクションを含めるインセンティブを持つことになる。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
同じトランザクションの複数の二重支払いバージョンがある場合、1つだけが有効となる。
それは私が尋ねている質問ではない。
私が懸念しているのは信頼の問題ではない。全員がきちんと振る舞ったとしても、どうすればグローバルに共有された見解を持つことが可能になるかという点だ。
誰がどのbitgoldコインを所有しているかについて、グローバルに共有された見解へ至るプロセスの規定が不十分だ。それが規定されて初めて、全員が正しく振る舞うインセンティブを持つかどうかを検討できる。
全員がXを知っているだけでは足りない。全員が「全員がXを知っている」ことを知り、さらに「全員が、全員がXを知っていることを知っている」ことを知る必要もある。これは、ビザンチン将軍問題と同じく、分散データ処理の古典的な難問だ。
この問題は、Xがきわめて大量のデータになりうる場合——つまり、ある時点においてすべてのbitgoldコインを誰が所有していたかについての合意——にさらに難しくなる。
その上さらに、合意が生じるような振る舞いをする動機を全員が持っている必要がある。動機づけられるべき振る舞いが何なのかが分からない以上、彼らにその動機があるとは私には見えない。
攻撃下でのシステムの分析を繰り返し述べている。だが、攻撃を受けていないときにシステムがどう振る舞うべきかが分からない限り、攻撃下でどう振る舞うかを語ることはできない。
トランザクション数が多ければ、あるノードの見解と別のノードの見解との食い違いを効率的に発見するのは難しい。しかも新しいトランザクションは絶えず到着し続けるため、たとえ全ノードが正直で、報告されたトランザクションがすべて正しい単一支払いであったとしても、2つのノードの見解が完全に一致することは決してない。
直近のある時点で誰がどのbitgoldコインを所有していたかについて、2つのノードが合意に至りやすいシステムを実現できるはずだが、それは簡単なことではない。
あるノードが、特定の時点で誰がどのbitgoldコインを所有していたかについての知識を表すハッシュを構築し、別のノードがそのハッシュを検証したいとする。合意が生じやすく、かつ正直できちんと振る舞うノード間の不一致が効率的に検出・解決される形でそれを行うのは、簡単なことではない。
仮に合意がどう生成されるかの仕様があったとしても、2つ目のノードがそのハッシュを検証するインセンティブを持つ理由は自明ではない。
システムは、合意に至るためにノードが直近のトランザクションについての見解を容易かつ低コストで変更できる一方で、確定性と不可逆性を提供するためには、いったん合意に達し、その上に新たなものが——とりわけ新しいbitgoldが古い合意の上に積み重ねられたなら、決定事項をさかのぼって変更するのが極めて困難になる、という形で機能しなければならない。
それがどう機能するかを述べるだけでは、実際にそう機能させる方法にはならない。
SNサトシ・ナカモト支払いの受取人は、それが有効であると信じる前に1時間ほど待たなければならない。ネットワークはそれまでにあらゆる二重支払いの競争を解決する。
攻撃について議論し続けている。当事者全員がきちんと行動した場合の通常の振る舞いが何なのかが私には明確でない以上、攻撃への対応を考えるのは難しい。
分散データベースは、すべてのデータベースが単一の所有者の意志に完全に従っている場合でさえ難しい。メッセージは失われ、リンクは切断し、同期の遅延は異常な水準になり、マシンごと燃えてしまうこともある。それでもネットワーク全体として、こうしたことすべてを乗り越えていかなければならない。
これをどう行うかを解明すること自体が、攻撃が完全に存在しない状況でさえ難しい。そのすべてにどう対処するかを解明できて初めて、次に攻撃が来る。
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
SNサトシ・ナカモトの投稿(2008年11月10日22:18 UTC)同じトランザクションの複数の二重支払いバージョンがある場合、1つだけが有効となる。
それは私が尋ねている質問ではない。
私が懸念しているのは信頼の問題ではない。全員がきちんと振る舞ったとしても、どうすればグローバルに共有された見解を持つことが可能になるかという点だ。
誰がどのbitgoldコインを所有しているかについて、グローバルに共有された見解へ至るプロセスの規定が不十分だ。
確かに、これらの事柄がどう扱われるのか、説明はまだ完全には明確でないと思うんだ。サトシも、設計をはっきりさせる一番の方法はソースコードを公開することかもしれないと言っているね。自分で細部を追ってみると、ルールはなかなか複雑になってきて、挙動をきちんと規定するには少なくとも擬似コードくらいは要ると分かったよ。だから、いっそ本物のコードを書いてしまうのは悪くない進め方じゃないかな。調べてみたらbitgold用のSourceForgeプロジェクトが立ち上がっていたんだ。まだコードは何もないけれどね。
ジェームズの具体的な質問——不完全なブロードキャストのために、異なるノードが異なるトランザクション集合を見たとき何が起きるか——だけど、私の理解はこうなんだ。各ノードは、いずれ最長になって勝つ可能性のある複数の「候補」ブロックチェーンを、潜在的にいくつも抱えられるよう備えておく必要がある。あるブロックチェーンが競合相手より十分に長くなったら、短い方は削除してしまっていいんだ。この長さの差は、攻撃者がどれだけの計算力を——「誠実な」ピアツーピアネットワークの処理能力に占める割合として——動員できるか、というノードの脅威モデル次第のパラメーターで、論文の中で見積もられているね。要するに、あるチェーンが最長のものから十分に引き離されてしまえば、もう追いつける見込みは実質的になくなる、というわけだ。
ジェームズが提起した問題を解くには、各ノードが候補チェーンごとに別々の保留トランザクションリストを持つ必要があると思うんだ。このリストには、ノードが(送金する側のブロードキャストで)受け取ったけれど、まだそのブロックチェーンには取り込まれていないトランザクションが全部入る。どの時点でも、ノードは最長のブロックチェーンを伸ばそうと頑張っていて、ハッシュ衝突を探しているブロックには、そのチェーンに紐づく保留トランザクションが全部含まれることになるんだ。
こうしておけば、候補チェーンが最長のものより短くなりすぎて削除されても、その中のトランザクションは失われずに済む。最初のトランザクションのブロードキャストを聞いたノードでは、最長チェーンに紐づく保留トランザクションリストにちゃんと残り続けるんだ。(他のノードからのブロックを通じて知ったトランザクションを、たとえそのブロックが最終的に最長ブロックチェーンに入らなくても保留リストに加えるべきか、とも考えてみたんだけど、それが要るのか、役に立つのかは正直まだ分からないな。)
こうしたルールがはっきりしてくれば、不完全な信頼性のもとでネットワークがどう振る舞うかを理解するのに、もっと形式的なモデル化が役立つだろうね。たとえば、あるトランザクションのブロードキャストを平均して割合fのピアツーピアノードが受け取るとすると、そのトランザクションが最長になる運命のチェーンに現れるまでに、ブロック生成時間の1/fくらいが経過すると見ていいんじゃないかな。それに、ピアツーピアネットワークのブロードキャスト自体も完全には信頼できないとなると、あるノードは平均していくつの候補チェーンを同時に把握しておけばいいのか、という疑問も出てくる。あるいはジェームズが先に挙げたように、ブロードキャストは信頼できても、遅くなりがちなフラッディングアルゴリズムに頼る場合、それが性能にどう響くんだろう?
JAジェームズ・A・ドナルドその上さらに、合意が生じるような振る舞いをする動機を全員が持っている必要がある。動機づけられるべき振る舞いが何なのかが分からない以上、彼らにその動機があるとは私には見えない。
動機のほうは、私はそこまで心配していないんだ。システムが次の条件を満たしてくれれば、それで十分だと思っている。
-
単一のノード運用者、あるいはネットワーク全体のリソースのごく一部しか支配しない少数のノード運用者の集まりが、他の参加者が誠実である限り、効果的に不正を行えないこと。
-
ノード運用者のロングテールが十分に大きく、少数のノードの集まりが全体リソースのごく一部しか支配できないこと。(ここで「テール」とは、各運用者が支配するリソース量に基づくランキングを指す。)
-
ビットコインのシステムが社会的に有用で価値あるものとなり、ノード運用者が自らの働きによって世界に有益な貢献をしていると感じられること(人々が善き目的のために計算資源を提供する各種の「@Home」計算プロジェクトに似ているね)。
そうであれば、単純な利他心だけでもネットワークをちゃんと動かし続けるのに十分だと、私には思えるんだ。
JAジェームズ・A・ドナルド分散データベースは、すべてのデータベースが単一の所有者の意志に完全に従っている場合でさえ難しい。メッセージは失われ、リンクは切断し、同期の遅延は異常な水準になり、マシンごと燃えてしまうこともある。それでもネットワーク全体として、こうしたことすべてを乗り越えていかなければならない。
これはとても良い指摘だね。こういう不完全さにネットワークがどう応じるのかを理解するには、もっと完全な仕様が要る。これからどんな詳細が出てくるのか、楽しみにしているよ。
ひとつ触れておくと、ビットコインは多くの点で二つの独立したアイデアだ。ジェームズがここで挙げている種類の問題を解決する方法、つまりグローバルに一貫性がありながら分散型のデータベースを作ること。そしてそれをウェイ・ダイのb-money(論文中で参照されている)に類似したシステムに使うこと、ただしアカウントベースではなくトランザクション/コインベースだ。グローバルで大規模に分散されたデータベース問題を解決することが、ジェームズが強調するように、おそらくより難しい部分だ。この目的にプルーフ・オブ・ワークを使うのは、私の考えでは、さらに検討する価値のある新しいアイデアだ。
ハル・フィニー
全員がXを知っているだけでは足りない。全員が「全員がXを知っている」ことを知り、さらに「全員が、全員がXを知っていることを知っている」ことを知る必要もある。これは、ビザンチン将軍問題と同じく、分散データ処理の古典的な難問だ。
PoWチェーンは、ビザンチン将軍問題の解決策だ。その文脈で言い換えてみよう。
何人かのビザンチン将軍が、それぞれコンピューターを持っていて、王のWi-Fiを、パスワードの総当たりで攻撃したい。パスワードの文字数は分かっている。ネットワークを刺激してパケットを発生させたら、限られた時間内にパスワードを破ってログを消去しなければならない。さもなければ発見されて面倒なことになる。過半数が同時に攻撃したときだけ、間に合うだけのCPUパワーがある。
攻撃の時刻がいつかは特に重要ではなく、全員が一致していることだけが重要だ。やる気のある者が時刻を発表し、最初に聞こえた時刻が公式の攻撃時刻となることに決まっている。問題は、ネットワークが一瞬では届かないことだ。二人の将軍がほぼ同時に別々の攻撃時刻を告げると、一方を先に聞く者と、もう一方を先に聞く者が出る。
そこで、プルーフ・オブ・ワークのチェーンを使う。各将軍は、最初に聞いた攻撃時刻を受け取ると、その時刻をハッシュに含めた、きわめて難しいプルーフ・オブ・ワークの問題をコンピューターに解かせる。全員で一斉に取り組んでも、誰かが解を見つけるまで10分はかかる難しさだ。将軍の一人が解を見つけると、それをネットワークに流す。全員が、いま解いている問題を、その解をハッシュに含めたものに切り替える。別の攻撃時刻で解いていた者も、こちらに乗り換える。こちらのチェーンのほうが長くなったからだ。
2時間後には、一つの攻撃時刻が、12個のプルーフ・オブ・ワークのチェーンでハッシュされているはずだ。どの将軍も、チェーンの難易度を確かめるだけで、1時間あたりどれだけのCPUパワーが並行して注がれたかを見積もれる。決められた時間にそれだけの計算を積むには、過半数のコンピューターが必要だったはずだと分かる。プルーフ・オブ・ワークはまさに将軍たちがそれに取り組んだ証拠なので、全員がそれを見ていたはずだ。プルーフ・オブ・ワークチェーンに表れたCPUパワーがパスワード解読に十分であれば、合意された時刻に安全に攻撃できる。
尋ねられた同期、分散データベース、全体で一致した見え方の問題は、どれもプルーフ・オブ・ワークチェーンで解ける。
各ノードは候補チェーンごとに別々の保留トランザクションリストを持つ必要があると思うんだ。 ……あるノードは平均していくつの候補チェーンを同時に把握しておけばいいのか、という疑問も出てくる。
幸いにも、現在の最良ブランチに対する保留トランザクションプールのみを維持すれば十分だ。新しいブロックが最良ブランチに到着すると、ConnectBlockがそのブロックのトランザクションを保留トランザクションプールから削除する。別のブランチがより長くなった場合、フォークまでのメインブランチに対してDisconnectBlockを呼び出し、ブロックのトランザクションを保留トランザクションプールに戻し、新しいブランチに対してConnectBlockを呼び出し、両方のブランチに含まれていたトランザクションを吸い上げる。このような再編成は稀で浅いものになると予想される。
この最適化により、候補ブランチは実際にはほとんど負担にならない。ディスク上に存在するだけで、メインチェーンにならない限り注意を払う必要がない。
HFハル・フィニーあるいはジェームズが先に挙げたように、ブロードキャストは信頼できても、遅くなりがちなフラッディングアルゴリズムに頼る場合、それが性能にどう響くんだろう?
ブロードキャストはほぼ完全に信頼できるだろう。TCP送信が今日ドロップされることはめったにないし、ブロードキャストプロトコルにはしばらく後に他のノードからデータを取得するリトライメカニズムがある。実際にブロードキャストが予想より遅いことが判明した場合、リソースの無駄を避けるためにブロック間の目標時間を増やす必要があるかもしれない。ブロックを生成するのにかかる時間よりもはるかに短い時間でブロックが伝播することを望んでいる。そうでなければ、ノードは廃れたブロックの作業に時間を費やしすぎることになる。
コンピューターがランダムに支払いを送信し、ランダムにパケットをドロップする自動テストを実行する予定だ。
HFハル・フィニー
- ビットコインのシステムが社会的に有用で価値あるものとなり、 ノード運用者が自らの働きによって世界に有益な貢献をしていると 感じられること(人々が善き目的のために計算資源を提供する 各種の「@Home」計算プロジェクトに似ているね)。
そうであれば、単純な利他心だけでもネットワークを ちゃんと動かし続けるのに十分だと、私には思えるんだ。
うまく説明できれば、リバタリアンの目にはとても魅力的に映る。ただ、私は言葉よりコードの方が得意なのだが。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
さて……。自分なりの理解でこのプロトコルを要約してみる。
論文に書かれていない運用上の細部は、自分の「設計感覚」が「これは必須の抜けだ」「これは『当然の』やり方だ」と告げる部分で補っている。
まず、人々は計算機のパワーを費やしてコインのプールを作り、それをマネーとして使う。各コインは、そのコインが作られた時点でマネーに対して有効だった基準を満たすプルーフ・オブ・ワークだ。作成時刻 ( ひいてはその時の基準 ) は後からでも検証できる。なぜなら、そのコインがトランザクションチェーンに登場した瞬間が見え、そこから「合意ビュー」におけるすべての使用履歴をたどれるからだ。 ( コイン生成をリンク追加と結びつける話は後述する )
コインを使う際、買い手と売り手は ( ブラインド化された ) トランザクション記録にデジタル署名し、それを多数のノードにブロードキャストする。これらのノードの目的はコインの所有権に関する合意の追跡だ。誰かが二重支払いを行った場合、そのトランザクション記録はブラインドを解除でき、不正者の身元が明らかになる。これはかなり標準的なカットアンドチューズアルゴリズムで実現される。買い手はいくつかのチャレンジに対して秘密分散の値で応答し、売り手は「ブラインドを解除せよ」と求めて、一つを残して全部を検査する。そして、そのうちの任意の二つが揃えば買い手の身元を特定できる秘密分散値が確かに含まれていることを検証する。この場合、売り手はブラインド解除済みの使用記録が「おそらく」有効な秘密分散値を含んでいると受け入れる。
コインの所有権に関する合意を追跡するノードはループの中にいる。すべてのノードが、これまで受信した最長のチェーンに「リンクを追加」しようとしている。各ノードは、「合意」された署名済みチェーンにまだ含まれていない、報告されたトランザクションのプールを持っている。これをプール「A」と呼ぶことにする。ノードはチェーンにリンクを追加するため、プールAのすべてをプール「L」に移し、CPU集約型のデジタル署名アルゴリズムを使って、新しいブロックLを含むチェーンに署名する。結果として、プールLに保持していたすべてのトランザクション記録とそのノードのデジタル署名を含むブロックで、チェーンが延長される。この間にも新しいトランザクション記録は届き続け、次の作業サイクルのために再びプールAに入る。
作業中に、延長しようとしているチェーンと同じ長さのチェーンを受け取ることもある。そのチェーンでは、最後の数本の「リンク」が、自分が作業しているチェーンとは共通でないリンクだ。そういうチェーンは無視する。 ( ? 本当に無視していいのか? 後でもう一度見直さねばならない状況はどんな時か? それらに基づく長いチェーンが現れれば、そこに含まれているのだから、という前提で )
しかし、作業中に_より長い_チェーンを受け取った場合、直ちに新しいリンク内のすべてのトランザクションをチェックする。二重支払いが含まれていないこと、およびすべての新しいリンクの「ワークファクター」が適切であることを確認するためだ。もし二重支払いが含まれていれば、二重支払いの証拠となる「トランザクション」を作成し、自分のプールAに追加してブロードキャストし、作業を続ける。「新しい」リンクのどれかに不適切なワークファクター ( つまり、ルール上「正当」と見なせるだけのCPUを誰かが投じていない場合 ) があれば、そのリンクを作ったノードによるプロトコル違反の証拠となる新しい「トランザクション」を作成し、ブロードキャストし、プールAに追加して、そのチェーンを拒否する。二重支払いがなく、まだ見ていないすべてのリンクのワークファクターが適切な場合は、その新しいチェーンを合意として受け入れる。
新しいチェーンが受け入れられた場合、自分が現在追加中のリンクは諦め、プールLからすべてのトランザクションをプールAに戻し ( 作業開始以降に受信または作成したトランザクションと合わせて )、新しいチェーンの中のリンクの一部として既に含まれているトランザクション記録をプールAから除外し、新しいチェーンを延長しようと再び作業を開始する。
自分の新しいリンクでチェーンの延長を完了したら、それをブロードキャストし、作業開始以降にプールAに蓄積したすべてのトランザクションを使って、直ちにまた新しいリンクの作業を始める。
これで合っているか?
最大の技術的問題:
「チェーン」が、最速の3つか4つのノードが足したリンクだけでできてしまわないようにする仕組みはあるのか? だって、ブロードキャストされたトランザクション記録がその3〜4ノードに届かないことは簡単にあり得る。そうなって、かつそのノードがチェーンを支配し続ければ、そのトランザクションは永久に追加されないかもしれない。
これを解決するには、トランザクションの伝播可能性を証明できるようにするか、あるノードのワークファクターを、そのノードの直近のリンク追加から何リンク追加されたかに応じて変動させる必要がある。
残念ながら、どちらの対策もソックパペット ( なりすまし複数アカウント ) で打ち破られる。これはおそらく現状のこのプロトコルにおける最悪の問題だ。ノードのアイデンティティ ( 鍵 ) を制御し、人々が新しいソックパペットを作るのを防ぐ、何らかの中央管理点が必要になる。
伝播可能性の証明とはこういう意味だ。ボブがアリスから新しいチェーンを受け入れる際、アリスが自分のプール「A」と「L」のすべてのトランザクションを持っているか ( あるいは入手するか ) を確認する必要がある。ボブはそれらをアリスに送り、アリスは受信した証拠として署名付きハッシュを返す。アリスがこのトランザクションのブロックを受け取った後、アリスが追加したリンクを含む後続のチェーンが、そのリンクまでに、もしくはそれ以前にこれらのトランザクションを含んでいなければ、ボブはアリスに送ったブロックとアリスの署名を、アリスがプロトコル違反した証拠として、一つのトランザクションの形で公開できるはずだ。ソックパペットはこれを打ち破る。なぜなら、アリスは後続のチェーンに署名する際、新しい鍵を使って別ノードのふりをすればよいだけだからだ。
新規リンクの数に応じてワークファクターを変動させる方式を採れば、結局のところ最も速い3〜4ノードによる支配に戻ってしまう。ただし今度はその支配者たちに、ワークファクターのペナルティを回避するために使われる600個ほどのソックパペットが加わるだけだ。
ソックパペット問題を解決するか、もしくは新しい鍵の生成を制御する中央点があると受け入れるなら、コインの生成は「合意」チェーンにブロックを成功裏に追加する行為と結びつけるべきだ。これは単純に実現できる。コインの生成は一つのトランザクションであり、そのブロック内の他のすべてのトランザクションと共に追加される。ただし、リンクごとに作れるコインは一つだけで、当然ながら、自分のバージョンのチェーンが受け入れられなかった場合、「受理された」ビューでは自分はそのコインを持っていないし、使うこともできない。これが、合意データベースを維持する人々にCPUサイクルを費やす動機を与える。とりわけ上で述べた、自身の直近リンク以降に追加されたリンク数によるワークファクターの変動が、最も速い3〜4ノードだけでなく全員に、時折コインを作る機会を保証するからだ。
また、チェーンにリンクを追加する作業要求は、過去一週間にそのチェーンに追加されたリンクの数に応じて ( これも指数的に ) 変動させ、コイン生成 ( したがってインフレ ) の率を厳格に制御できるようにすべきだ。
これがスケールするためにはコインの集約が必要だ。誰かが額面1のコイン10枚を引退させ、額面10の新しいコインを作るような「証明可能な」トランザクションが必要になる。これは難しくない。すでに用意されているのと同じ基盤で実現できる。単純にチェーンの一部となり、そのチェーンが合意として受け入れられたとき、全員がそれが起きたことを見ることができる。
Bear
できるだけ早くソースコードをリリースできるよう、急ぐつもりだ。これらの実装に関する疑問をすべて解消する参考になるはずだ。
RDレイ・ディリンジャーの投稿(2008年11月15日02:20 UTC)コインを使う際、買い手と売り手は ( ブラインド化された ) トランザクション記録にデジタル署名する。
署名するのは買い手のみであり、ブラインド化はない。
RDレイ・ディリンジャー誰かが二重支払いを行った場合、そのトランザクション記録は ブラインドを解除でき、不正者の身元が明らかになる。
身元は使わないし、事後の救済に頼ることもない。すべては予防だ。
RDレイ・ディリンジャーこれはかなり標準的なカットアンドチューズアルゴリズムで行われ、 買い手は秘密分散を使ったいくつかのチャレンジに応答する
チャレンジも秘密分散もない。基本的なトランザクションはセクション2の図に示されているものだ。前のトランザクションの公開鍵を満たす(買い手の)署名と、次回使用時に満たす必要がある(売り手の)新しい公開鍵だ。
RDレイ・ディリンジャー作業中に延長しようとしているチェーンと同じ長さだが、 最後の数「リンク」が取り組んでいるチェーンと共通でない リンクであるチェーンを受信することもある。 これらは無視する。
その通り、長さが等しい場合は、最初に受信したものを保持することで同点を解消する。
RDレイ・ディリンジャーもし二重支払いが含まれていれば、二重支払いの証拠となる 「トランザクション」を作成し、自分のプールAに追加して ブロードキャストし、作業を続ける。
そのような「二重支払いの証拠」の報告は必要ない。同じチェーンに両方の支払いが含まれている場合、そのブロックは無効であり拒否される。
ブロックに十分なプルーフ・オブ・ワークがない場合も同様だ。そのブロックは無効であり拒否される。それについてレポートを回覧する必要はない。すべてのノードがそれを確認し、リレーする前に拒否できる。
2つの競合するチェーンがあり、それぞれが同じトランザクションの異なるバージョンを含み、一方が資金をある人に、もう一方が同じ資金を別の人に送ろうとしている場合、どちらの支払いが有効かを裁定するのがプルーフ・オブ・ワークチェーンのすべてだ。
我々は二重支払いを「監視」してアラームを鳴らし不正者を捕まえるのではない。単にどちらの支払いが有効かを裁定するのだ。トランザクションの受取人は、解決のための時間を確保するために数ブロック待つ必要がある。不正を試みる者はすべて好きなだけ二重支払いを同時に試みればよいが、数ブロック以内に支払いの1つが有効となり、他は無効となる。メインチェーンに既に支払いが存在すれば、後の二重支払いは即座に拒否される。
まだチェーンに入っていないが、すべてのノードのプールに既にある場合でも、2番目の支払いは既に最初の支払いを持っているすべてのノードによって拒否される。
RDレイ・ディリンジャー新しいチェーンが受け入れられた場合、現在のリンクの追加を 諦め、プールLからすべてのトランザクションをプールAに 戻し(作業開始以降に受信または作成したトランザクションとともに)、 新しいチェーンのリンクの一部であるトランザクション記録を プールAから除外し、新しいチェーンの延長を 再度試みて作業を開始する。
その通り。新しいトランザクションが入るたびにリフレッシュも行うので、LはほぼすべてのA内のものを常に含んでいる。
RDレイ・ディリンジャーCPU集約型のデジタル署名アルゴリズムで 新しいブロックLを含むチェーンに署名する。
これは署名ではなく、Hashcash方式のSHA-256プルーフ・オブ・ワーク(ゼロの部分的プリイメージ)だ。
RDレイ・ディリンジャー「チェーン」が、最速の3つか4つのノードが足したリンクだけでできてしまわないようにする仕組みはあるのか? だって、ブロードキャストされたトランザクション記録がその3〜4ノードに届かないことは簡単にあり得る。そうなって、かつそのノードがチェーンを支配し続ければ、そのトランザクションは永久に追加されないかもしれない。
これをCPU集約型のデジタル署名として考えている場合、長い操作を最初に完了する競争であり、最も速い者が常に勝つと考えているかもしれない。
プルーフ・オブ・ワークはHashcash方式のSHA-256衝突発見だ。毎秒数百万回のハッシュを行うメモリーレスプロセスであり、毎回小さな確率で見つかる。最速の3つか4つのノードが支配できるのは、全体のCPUパワーに占める割合の分だけだ。いつ誰が解を見つける確率も、その人のCPUパワーに比例する。
トランザクション手数料があるため、ノードは受信したすべてのトランザクションを受け入れて含めるインセンティブを持つ。作成されたコインの総数が所定の上限に達すると、ノードは最終的にトランザクション手数料のみで報酬を受ける。
RDレイ・ディリンジャーまた、チェーンにリンクを追加する作業要求は、過去一週間にそのチェーンに追加されたリンクの数に応じて ( これも指数的に ) 変動させ、コイン生成 ( したがってインフレ ) の率を厳格に制御できるようにすべきだ。
その通り。
RDレイ・ディリンジャーこれをスケールさせるにはコインの集約が必要だ。 誰かが単一額面のコイン10枚を引退させ、 額面10の新しいコイン1枚を作成する「証明可能な」 トランザクションが必要だ。
すべてのトランザクションがこれだ。セクション9、価値の結合と分割を参照。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
できるだけ早くソースコードをリリースできるよう、急ぐつもりだ。これらの実装に関する疑問をすべて解消する参考になるはずだ。
RDレイ・ディリンジャーの投稿(2008年11月15日02:20 UTC)コインを使う際、買い手と売り手は ( ブラインド化された ) トランザクション記録にデジタル署名する。
署名するのは買い手のみであり、ブラインド化はない。
RDレイ・ディリンジャー誰かが二重支払いを行った場合、そのトランザクション記録はブラインドを解除でき、不正者の身元が明らかになる。
身元は使わないし、事後の救済に頼ることもない。すべては予防だ。
なるほど、これは意外だ。もし買い手 / 売り手のアイデンティティを使わないのなら、使われているコインの ( 受け取った記録のある ) 真の所有者によって支払いが行われているかどうかを確認していないことになる。
考えるうえで有用なアイデンティティのカテゴリーは三つある。カテゴリー1は公開。現実世界のアイデンティティが記録され、すべてのトランザクションに付随する。カテゴリー2は仮名。システム内に永続的な「アイデンティティ」があり、ある何かが別の何かと同じ仮名によって行われたかを人々は見ることができるが、仮名と現実世界のアイデンティティを必ずしも結びつける手段はない。カテゴリー3はリンクできない匿名。アイデンティティという概念は、永続的なものであれそれ以外であれ、存在しない。あるトランザクションに関与した主体が、別のトランザクションに関与した主体と同じであるかどうか、誰も言うことも証明することもできない。
見たところカテゴリー3を主張しているようだが、そうなのか、それともカテゴリー2か? 多くの人は匿名プロトコルと仮名プロトコルを区別しないので、ここで正確に何を意味しているのかを尋ねる価値がある。
ともあれ、あなたが言ったことに ( 自分の想像できる限り ) ほぼそのまま、つまり結びつけ不可能な匿名性を意味していたという前提で進めよう。これは、「アイデンティティ」の代わりに、使用者がコインの真の所有者だけが知る秘密を知っていることを示さなければならない、ということを意味する。一つのやり方としては、コインを受け取る人が非対称鍵ペアを生成し、その片方をトランザクションと共に公開する。後でそのコインを使うためには、非対称鍵ペアのもう片方を所持していることを示さねばならない。おそらく、新しい売り手が提供する鍵にそれで署名する形だ。こうすると「アイデンティティ」については何も証明できないが、コインの使用者が、コインを受け取った人が知る秘密を知っている誰かであることは証明できる。
そして、あなたが次に述べていることは、これを裏付けているように見える:
SNサトシ・ナカモトチャレンジも秘密分散もない。基本的なトランザクションはセクション2の図に示されているものだ。前のトランザクションの公開鍵を満たす(買い手の)署名と、次回使用時に満たす必要がある(売り手の)新しい公開鍵だ。
ただし、これがアイデンティティそのものを含まなかったとしても、使用を行う主体は、以前にコインを受け取った主体と結びつけ可能なままだ。つまり、これらのトランザクションは結びつけ可能だ。これに対抗するためには、コインの所有者は、普通のトランザクションと他者からは区別できないトランザクションを作る必要がある。その中で新しい鍵ペアを生成し、コインをその所持者に移す ( つまり、ある一人のソックパペットから別の一人のソックパペットへ「使わせる」 )。所有者の現実世界のアイデンティティは変わらないが、コインを使った主体と結びつけ可能だった取引はその結びつきが切れる。カテゴリー3の結びつけ不可能性のためには、これをランダムな回数 — おそらく1回から6回程度 — 行う必要がある?
ところで、改行を覚えてくれないか?? 行が馬鹿みたいに右へスクロールしていって、あなたが一体何を言っているのか見るためにスクロールしなければならず、返信する前には改行を加えるために編集しなければならない。
SNサトシ・ナカモトRDレイ・ディリンジャーもし二重支払いが含まれていれば、二重支払いの証拠となる「トランザクション」を作成し、自分のプールAに追加してブロードキャストし、作業を続ける。
そのような「二重支払いの証拠」の報告は必要ない。同じチェーンに両方の支払いが含まれている場合、そのブロックは無効であり拒否される。
ブロックに十分なプルーフ・オブ・ワークがない場合も同様だ。そのブロックは無効であり拒否される。それについてレポートを回覧する必要はない。すべてのノードがそれを確認し、リレーする前に拒否できる。
うーん、それで安心できるかは自信がない。つまり、協力しないノードを特定して排除する努力はしないということか? これは面倒なことになるし、DOS攻撃も受けそうだと思う。
SNサトシ・ナカモト2つの競合するチェーンがあり、それぞれが同じトランザクションの異なるバージョンを含み、一方が資金をある人に、もう一方が同じ資金を別の人に送ろうとしている場合、どちらの支払いが有効かを裁定するのがプルーフ・オブ・ワークチェーンのすべてだ。
なるほど、「同じ」トランザクションと言って、明らかに異なるトランザクションを指しているとき、つまり二重支払いのことだろう? 同じ鍵で署名された二つのトランザクション?
SNサトシ・ナカモト我々は二重支払いを「監視」してアラームを鳴らし不正者を捕まえているのではない。単にどちらの支払いが有効かを裁定しているだけだ。トランザクションの受取人は、裁定が完了する時間を確保するために数ブロック待たねばならない。
それまで…… 何までだ? 取引が取り消せなくなったと、誰がどうやって分かる? 「数ブロック」って3つか? 30か? 100か? ノード数に依存するのか? ノード数に対して対数的なのか線形なのか?
SNサトシ・ナカモト不正を試みる者はすべて好きなだけ同時に二重支払いを試みればよいが、数ブロック以内に支払いの一つが有効となり、他は無効となる、それだけのことだ。
しかしアイデンティティがない以上、使用が無効になっても不正者にはデメリットがない。二重支払いで得ようとした商品 ( ウェブサイトへのアクセス、ダウンロード、その他何でも ) を既に受け取っていれば、損するのは「無効な」コインを抱える商人の方だ。ただし商人が、支払いを受けたとみなす前にあの魔法の「数ブロック」 ( しかも何ブロックなのか、どうやって知ればいい? ) を待つなら別だが。
消費者は、コインを使ってからそれが使えるようになるまで一時間も待たされるなら、使ってくれないだろう。商人の方も、客が二重支払いしたためにコインが無効と判明したとき、その客に逆請求する手段がなければ、使わないだろう。
SNサトシ・ナカモトまだチェーンに入っていないが、すべてのノードのプールに既にある場合でも、2番目の支払いは既に最初の支払いを持っているすべてのノードによって拒否される。
ということは、最初の同時使用のブロードキャストどうしが干渉し合った時点で早期に捕捉される可能性があるということだ。ここでは、ブロードキャストを売り手が行うと想定している。買い手側には、使用記録を広く流布させない動機が働きうるからだ。
SNサトシ・ナカモトRDレイ・ディリンジャー新しいチェーンが受け入れられた場合、自分が現在追加中のリンクは諦め……新しいチェーンを延長しようと再び作業を開始する。
その通り。新しいトランザクションが入るたびにリフレッシュも行うので、LはほぼすべてのA内のものを常に含んでいる。
なるほど、これは膨大かつ固定回数のCPUサイクルを必要とするプルーフ・オブ・ワークと、少ないCPUサイクルで済むが成功確率が極小であるプルーフ・オブ・ワークとの大きな違いだ。作業中にデータセットを変更しても、最初からやり直しになるわけではない。今回の場合、最近受信したトランザクションを自分が作業中のリンクから除外して保持しておく必要がないという点で、これは好都合だ。
SNサトシ・ナカモトRDレイ・ディリンジャー「チェーン」が、最速の3つか4つのノードが足したリンクだけでできてしまわないようにする仕組みはあるのか?
これをCPU集約型のデジタル署名として考えている場合、長い操作を最初に完了する競争であり、最も速い者が常に勝つと考えているかもしれない。
その通り。自分が抱いていた誤解はそれだった。繰り返すが、膨大かつ固定回数のCPUサイクルを必要とするプルーフと、少ないCPUサイクルで済むが成功確率が極小であるプルーフとの違いだ。
SNサトシ・ナカモト誰でもいつでも解を見つける確率は、そのCPUパワーに比例する。
これはワークファクターのランダムな変動のようなものだ。この点で、これはあなたに有利に働く。
SNサトシ・ナカモトトランザクション手数料があるため、ノードは受信したすべてのトランザクションを受け入れて含めるインセンティブを持つ。作成されたコインの総数が所定の上限に達すると、ノードは最終的にトランザクション手数料のみで報酬を受ける。
「トランザクション手数料」がどう機能し、トランザクションを行う主体からネットワークを運営する人々へどうやってマネーが流れるのか、私には理解できない。ただ、チェーンへのリンク追加がノードにコインを作る権利を与えるなら、経済的効果は ( 多少ランダム化されているが ) 同じになる。だから私はそちらの方式を支持する。
また、異なるノードの計算能力は、歴史のある時点においても二桁の幅で変動しうると想定しておく必要がある。
Bear
1つの方法は、コインの受取人に非対称鍵ペアを生成させ、 その半分をトランザクションとともに公開することだ。 後でコインを使うためには、非対称鍵ペアの もう半分の所有を証明する必要がある。 おそらく新しい売り手が提供する鍵に署名することで。
その通り、ECCデジタル署名だ。すべてのトランザクションで新しい鍵ペアが使用される。
人を特定する仮名、という意味での仮名ではない。だが、コインの次の動きがそのコインの持ち主のものだと分かる、という意味では、少なくとも少しは仮名だ。
RDレイ・ディリンジャーうーん、それで安心できるかは自信がない。つまり、協力しないノードを特定して排除する努力はしないということか? これは面倒なことになるし、DOS攻撃も受けそうだと思う。
誰かを識別することに依存はしていない。あなたが言ったように、それは無駄であり、ソックパペットで簡単に破られる。
誰かが本物であることを確立するクレデンシャルは、CPUパワーを提供する能力だ。
RDレイ・ディリンジャーそれまで…… 何までだ? 取引が取り消せなくなったと、誰がどうやって分かる? 「数ブロック」って3つか? 30か? 100か? ノード数に依存するのか? ノード数に対して対数的なのか線形なのか?
セクション11が攻撃下での最悪のケースを計算している。普通は5〜10ブロックで足りる。ネットワーク全体を相手にした攻撃をしてまで盗む値打ちのない物を売るなら、実際にはもう少し詰めてもいい。
RDレイ・ディリンジャーしかし身元がない場合、既に二重支払いで得た 商品(ウェブサイトへのアクセス、ダウンロードなど)を 受け取っていれば、支払いが無効になっても 彼らにとってデメリットはない。その魔法の「数ブロック」 (何ブロックかどうやって知るのか?)が経過するまで 支払い済みとして扱わなければ、商人は「無効な」コインを 掴まされることになる。
消費者は、コインを使ってからそれが使えるようになるまで一時間も待たされるなら、使ってくれないだろう。 商人の方も、客が二重支払いしたためにコインが無効と判明したとき、その客に逆請求する手段がなければ、使わないだろう。
これはバージョン2の問題であり、ほとんどのアプリケーションでかなり満足のいく解決が可能だと考えている。
競争はトランザクションをネットワーク上で最初に広めることだ。6次の隔たりを考えれば、指数関数的に広がる。トランザクションが十分に広がるまでには、2分ほどしかかからない。そうなれば、遅れて始めた競合者が、最初のトランザクションがネットワーク全体に行き渡る前に非常に多くのノードを獲得できる見込みは、ほとんどない。その2分間、商人のノードは二重支払いトランザクションを監視できる。二重支払い者は商人に知られずに代替トランザクションを世界に一斉に送り出すことはできないため、開始前に待つ必要がある。
本物のトランザクションが90%に到達し、二重支払いトランザクションが10%に到達した場合、二重支払い者は支払わずに済む確率がわずか10%で、90%の確率でお金が使われてしまう。ほとんどの種類の商品に対して、詐欺師にとって割に合わない。
情報ベースの商品、例えばウェブサイトへのアクセスやダウンロードは転売不可能だ。ウェブサイトへのアクセスやダウンロードを盗んで生計を立てることはできない。それを盗むならファイル共有ネットワークに行けばいい。ほとんどの即時アクセス製品は盗む大きなインセンティブがない。
商人が実際に盗難の問題を抱えている場合、顧客に2分待ってもらうか、メールで何かを待ってもらうことができ、多くの商人は既にそうしている。本当に最適化したい場合で、大きなダウンロードの場合、トランザクションが二重支払いとして戻ってきたらダウンロードの途中でキャンセルできる。ウェブサイトへのアクセスの場合、通常は顧客に5分間アクセスさせて、拒否された場合はアクセスを遮断しても大した問題ではない。そういうサイトの多くには、もともと無料トライアルがある。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
幸い、現在の最良の分岐のための 保留トランザクションプールだけを保持すれば十分だ。
これは我々が知っている、つまり通信と データストレージが正常に動作している誠実で 行儀の良いピアが、現在の最良の分岐が何であるかを 知っていることを要求する——
ノードは自分が持っている最良の分岐の保留トランザクションプールだけを持てばよいということだ。現在最良の分岐だと考えている分岐のことだ。それがブロックを作ろうとしている分岐であり、プールが必要なのはそのためだけだ。
JAジェームズ・A・ドナルドブロードキャストはおそらくほぼ完全に 信頼できるだろう。
各メッセージが少なくとも1回は到着すると 仮定するのではなく、頻繁に到着に失敗する メッセージによって伝えられる場合でも 情報が到着するようなメカニズムを 作る必要がある。
ピアネットワーキングのブロードキャストメカニズムはカバーできていると思う。
各ノードは隣接ノードに、持っている新しいブロックとトランザクションのハッシュのインベントリリストを送信する。隣接ノードはまだ持っていないアイテムを要求する。タイムアウト後にアイテムが届かない場合、そのアイテムを持っていた別の隣接ノードにリクエストする。すべてまたはほとんどの隣接ノードが最終的に各アイテムを持つはずなので、1つとの通信が失敗しても、他の任意のノードから1つずつ試して取得できる。
インベントリ-リクエスト-データのスキームは少しレイテンシを導入するが、余分なデータブロックを送信キューに入れないことで帯域幅を節約し、最終的にはスピードの向上に役立つ。
JAジェームズ・A・ドナルドその設計の概要と提案を示したのは、大きな前進だ。だが、悪魔は細部に宿る。
この一年半、コードを書きながら、そうした細かい点は、すべて詰め切れていると思う。数は多かった。機能の細部は論文には書いていないが、ソースコードはもうすぐ出す。主なファイルはあなたに送った(いまは頼まれれば渡している。正式なリリースもじきだ)。
Satoshi Nakamoto
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com
ビットコインの電子キャッシュの議論は、いったんここで終わりにしたい。今は、同じ話を行ったり来たりするより、それぞれが論文を書いたほうがうまく進む議論が多い。いずれサトシ(か誰か)が詳しいものを書いて投稿したら、もう一度この議論をすればいい。
Perry
--
Perry E. Metzger perry@piermont.com
暗号学メーリングリスト 購読をやめるには、「unsubscribe cryptography」と書いたメールをmajordomo@metzdowd.comへ送ってください