サトシ ↔ ダスティン・トランメル メール

On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトの投稿（2009年1月8日 19:27 UTC）

ピアツーピアネットワークを用いて二重支払いを防止する新しい電子マネー システム、ビットコインの初回リリースをお知らせする。 サーバーや中央権威を一切持たない、完全な分散型システムだ。

ちょうどそちらの論文を読み進めているところだ。タイムスタンプサーバーの 節で新聞や Usenet に言及されていたので、もしまだ知らなければ 興味を持つかもしれないと思った。

http://www.publictimestamp.org/

ところで、こちらもアルファコードをワークステーションの 1 台で動かして いる。これまで「Generated」のメッセージが 2 件出ているが、 「Credit」欄は 0.00 のままで残高も変わっていない。これはコインが 有効になるための経過時間／成熟の要件によるものか？

それでは。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ダスティン・トランメルのメール（2009年1月11日 23:14 UTC）

ちょうどそちらの論文を読み進めているところだ。タイムスタンプサーバーの 節で新聞や Usenet に言及されていたので、もしまだ知らなければ 興味を持つかもしれないと思った。

http://www.publictimestamp.org/

ありがとう、これは知らなかった。よく作り込まれている。 もっと古いものが長らく動いていて、ハッシュを Usenet に公開している。 このサービスが Usenet を使っていないのは意外だ。もっとも、最近では 自動投稿用に Usenet へのアクセス権を取るのが難しいから仕方ないかもしれない。 雑誌や新聞にハッシュを掲載してもらえれば、彼らの目的（法廷での証拠利用） にはずっと有効に働くだろう。ビットコインとすべてのタイムスタンプサーバーは、 事項を定期的にブロックにまとめてチェーンへとハッシュ化していくという 基本的な機能を共有している。

ところで、こちらもアルファコードをワークステーションの 1 台で動かして いる。これまで「Generated」のメッセージが 2 件出ているが、 「Credit」欄は 0.00 のままで残高も変わっていない。これはコインが 有効になるための経過時間／成熟の要件によるものか？

そう、Credit 欄は成熟するまで 0.00 のままで、成熟すると 50.00 に なる。成熟するまでは Credit 欄を空欄にしておいた方が分かりやすいだろうか？ 取引の詳細（行をダブルクリックしたときに表示される画面）に 仕組みの説明文を入れるべきだろう。（そもそも行をダブルクリックで 詳細を見られることに気付いてもらえていただろうか？）

まだなら v0.1.3 に更新しておいてほしい。このバージョンで安定性が かなり上がった。

Satoshi

On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月12日 18:52 UTC）

ありがとう、これは知らなかった。よく作り込まれている。 もっと古いものが長らく動いていて、ハッシュを Usenet に公開している。 このサービスが Usenet を使っていないのは意外だ。もっとも、最近では 自動投稿用に Usenet へのアクセス権を取るのが難しいから仕方ないかもしれない。 雑誌や新聞にハッシュを掲載してもらえれば、彼らの目的（法廷での証拠利用） にはずっと有効に働くだろう。ビットコインとすべてのタイムスタンプサーバーは、 事項を定期的にブロックにまとめてチェーンへとハッシュ化していくという 基本的な機能を共有している。

実は ‘proof-hashes’ という Google Group にハッシュブロックを投稿 していて、Usenet に投稿するのと似たような結果になる。

http://groups.google.com/group/proof-hashes

そのグループはこちらが運営していて、唯一の目的が proof-of-work ハッシュの アーカイブだ。よければアカウントを取得して、そちらのシステムからも ここに投稿するようにして構わない。

そう、Credit 欄は成熟するまで 0.00 のままで、成熟すると 50.00 に なる。成熟するまでは Credit 欄を空欄にしておいた方が分かりやすいだろうか？ 取引の詳細（行をダブルクリックしたときに表示される画面）に 仕組みの説明文を入れるべきだろう。（そもそも行をダブルクリックで 詳細を見られることに気付いてもらえていただろうか？）

いや、空欄よりも $0.00 と表示されている方が適切だと思う。 ただ、こちらのビットコインソフトウェアのエントリ（今 4 件ある）はすべて ‘unconfirmed’ と表示されているので、その意味するところが分からない。 ただコインが生成されていてまだ「成熟」していないだけだと 理解はできたが、ホワイトペーパーも読んでいたので、 そちらから概念を理解していたのかもしれない。コインが成熟したら、 新しい ‘credit’ トランザクションが生成されるのか、それとも 既存のコインベーストランザクション行の Credit 欄が更新されるのか？

いや、トランザクション行をダブルクリックすれば詳細が見られるとは 気付いていなかった…… 今やってみたが、現状ではトランザクション 行と同じ情報が表示されるだけだ。ここにもっと多くの情報を入れれば、 確かに有用になると思う。

まだなら v0.1.3 に更新しておいてほしい。このバージョンで安定性が かなり上がった。

こちらは 0.1.1 を実行していた…… これから更新する。新バージョン通知か 自動更新機能があった方が良いかもしれない (:

電子マネーと暗号はこちらが非常に興味を持っている 2 つの分野だ。 ご想像のとおり、暗号メーリングリストへの投稿を目にしてすぐに このプロジェクトに引き付けられた。フィードバックや新機能の検証など、 いつでも声をかけてくれ。喜んで協力する。

それでは。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月12日 18:52 UTC）

まだなら v0.1.3 に更新しておいてほしい。このバージョンで安定性が かなり上がった。

アップグレードで 2 つ問題があった。

以前のバージョン（ヘルプには 0.1.1 と書かれていたが、実際には 0.1.0 だったと思う）を閉じたとき、プロセスが終了しなかった。 UI は終了したが、プロセスは残ったままだ。バージョン 0.1.3 を 起動できるようにするには、手動でプロセスを kill する必要があった。

バージョン 0.1.3 を起動したところ、こちらのトランザクションエントリ 4 件は すべて依然として unconfirmed と表示されているが、Description が Generated (not accepted) に変わっている。これは、他のノードが先に チェーンを延ばし、こちらのコインが死んだブランチで生成されたという意味 か？ もしそうなら、以前のソフトウェアのインスタンスはなぜ即座に それを検知して、勝ち残ったブランチで採掘を始めなかったのか？ 0.1.0 のバグか？

このまま様子を見てみる……

それでは。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

もう 1 つ質問があったのだが…… CPU 性能が最も高い 1 つのノードが ビットコインの大半を生成して保有してしまうことを、何が妨げるのか？ 各ノードが他のノードから独立して動作しているのなら、あるノードが 他よりも大幅に高性能だった場合、そのノードが他のノードより先に 正しい解にたどり着く確率が高くなるのではないか？ 性能の低い ノードもときどき幸運に恵まれるかもしれないが、馬力差が大きい場合は 大半のビットコインが最も高性能なノードによって生成されることに なると思うのだが。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ダスティン・トランメルのメール（2009年1月12日 21:29 UTC）

実は ‘proof-hashes’ という Google Group にハッシュブロックを投稿 していて、Usenet に投稿するのと似たような結果になる。

http://groups.google.com/group/proof-hashes

そのグループはこちらが運営していて、唯一の目的が proof-of-work ハッシュの アーカイブだ。よければアカウントを取得して、そちらのシステムからも ここに投稿するようにして構わない。

いいな、いつだったか Usenet 上で同じようなグループを探したことが あったが、ぴったり合うものは見つからなかった。Google Groups の方が 投稿しやすいのは間違いないだろう。

Usenet や Google Group が補助的な防御として使える状況もある。 ビットコインはネットワーク全体の CPU 性能が小さい初期段階が一番 脆弱だ。もっとも、規模が小さければ攻撃する動機も小さいので、その分は 相殺される。最も簡単な解、つまりただ成長してこの段階を抜けるという 解で済むことを願っている。それでだめなら、本当に必要になったときに 備えて Google Group が役に立つ筋道もある。

ダスティン・トランメルのメール（2009年1月12日 21:29 UTC）

電子マネーと暗号はこちらが非常に興味を持っている 2 つの分野だ。 ご想像のとおり、暗号メーリングリストへの投稿を目にしてすぐに このプロジェクトに引き付けられた。フィードバックや新機能の検証など、 いつでも声をかけてくれ。喜んで協力する。

確かにこちらと関心が近いな。

90 年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された 第三者ベースのシステム（Digicash など）が 10 年以上にわたって失敗 続きだったあと、彼らはもう望みがないと見ている。今回は私の知る限り 初めて非信頼ベースのシステムを試みている、というところに彼らが 気付いてくれることを願う。

ダスティン・トランメルのメール（2009年1月12日 21:29 UTC）

コインが成熟したら、新しい ‘credit’ トランザクションが 生成されるのか、それとも既存のコインベーストランザクション行の Credit 欄が 更新されるのか？

既存のトランザクション行が更新される。

ダスティン・トランメルのメール（2009年1月12日 21:40 UTC）

バージョン 0.1.3 を起動したところ、こちらのトランザクションエントリ 4 件は すべて依然として ‘unconfirmed’ と表示されているが、Description が ‘Generated (not accepted)’ に変わっている。これは、他のノードが先に チェーンを延ばし、こちらのコインが死んだブランチで生成されたという意味 か？ もしそうなら、以前のソフトウェアのインスタンスはなぜ即座に それを検知して、勝ち残ったブランチで採掘を始めなかったのか？ 0.1.0 のバグか？

そのとおりだ、申し訳ない。これは 0.1.3 で修正したバグだ。 通信スレッドがブロックされてしまうので、接続はするけれども しばらくすると無音になる。ブロックを見つけてもネットワークに ブロードキャストできず、チェーンには取り込まれない。再起動するまでは、 ネットワークが自分を置いて先に進んでいることを知る情報も受け取れない。

このバグは bitcoin.exe が終了できなかった原因でもある。 通信スレッドがブロックされて終了できなかったのだ。ビットコインは 重要なトランザクションの途中である場合に備えて慎重なシャットダウンを するが、実際には kill しても完全に安全だ。

これらはすべて 0.1.3 で修正済みだ。IP を教えてくれれば、コインを いくらか送る。

ダスティン・トランメルのメール（2009年1月12日 21:49 UTC）

もう 1 つ質問があったのだが…… CPU 性能が最も高い 1 つのノードが ビットコインの大半を生成して保有してしまうことを、何が妨げるのか？ 各ノードが他のノードから独立して動作しているのなら、あるノードが 他よりも大幅に高性能だった場合、そのノードが他のノードより先に 正しい解にたどり着く確率が高くなるのではないか？ 性能の低い ノードもときどき幸運に恵まれるかもしれないが、馬力差が大きい場合は 大半のビットコインが最も高性能なノードによって生成されることに なると思うのだが。

これは「車が 2 倍速ければ必ず勝つ」というレースとは違う。 1 マイクロ秒以下で済む SHA-256 計算で、それぞれの試行は独立に成功確率を 持つ。あるコンピューターがハッシュ衝突を見つける確率は、その CPU 性能に比例する。性能が半分のコンピューターは半分のコインを得る、 それだけだ。

ダスティン・トランメルのメール（2009年1月12日 21:40 UTC）

このまま様子を見てみる……

経過を教えてくれ。何か問題があれば debug.log を送ってほしい。 それだけで何が起きたか分かることが多い。

Satoshi

On Tue, 2009-01-13 at 15:39 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月13日 01:55 UTC）

いいな、いつだったか Usenet 上で同じようなグループを探したことが あったが、ぴったり合うものは見つからなかった。Google Groups の方が 投稿しやすいのは間違いないだろう。

そう、あのグループは完全にオープンで、投稿に加入は不要だ（実は、 加入の方は意図的に難しくしていたと思う）。proof-hashes@googlegroups.com にメールを送れば、その本文がそのままグループに投稿される。

Usenet や Google Group が補助的な防御として使える状況もある。 ビットコインはネットワーク全体の CPU 性能が小さい初期段階が一番 脆弱だ。もっとも、規模が小さければ攻撃する動機も小さいので、その分は 相殺される。最も簡単な解、つまりただ成長してこの段階を抜けるという 解で済むことを願っている。それでだめなら、本当に必要になったときに 備えて Google Group が役に立つ筋道もある。

うむ、たとえばクライアントから 1 万ブロックごとに現行のブロックチェーン 全体を投稿させて、現時点の勝ち残った proof-of-work チェーンを ときどき記録に残しておく、というのは思いついた。

確かにこちらと関心が近いな。

そのとおりだ。

90 年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された 第三者ベースのシステム（Digicash など）が 10 年以上にわたって失敗 続きだったあと、彼らはもう望みがないと見ている。今回は私の知る限り 初めて非信頼ベースのシステムを試みている、というところに彼らが 気付いてくれることを願う。

うむ、それこそがこちらの目を引いた最大の特徴だった。本当の難所は、 人々に実際にビットコインを評価させ、通貨になるまで持っていくことに なるだろう。現状ではただのビットの集まりにすぎない……

これらはすべて 0.1.3 で修正済みだ。IP を教えてくれれば、コインを いくらか送る。

今のところ 24.28.79.95 だが、動的なので変わるかもしれない。 ただ、このアドレスは結構長く使えているので、こちらの DHCP クライアントが 更新に成功してアドレスを失わずに済んでいるといいのだが。ときどき 変わるが、当面はこのアドレスで大丈夫だと思う。

これは「車が 2 倍速ければ必ず勝つ」というレースとは違う。 1 マイクロ秒以下で済む SHA-256 計算で、それぞれの試行は独立に成功確率を 持つ。あるコンピューターがハッシュ衝突を見つける確率は、その CPU 性能に比例する。性能が半分のコンピューターは半分のコインを得る、 それだけだ。

ああ、なるほど…… それぞれの試行はルーレットの一回の回転のような ものか、他のすべての試行から独立していて、CPU 性能が高いほど 他のノードよりも当たりを多く引ける、と。残念ながらこちらが複雑な数学を 理解する能力は、暗号への興味の高さに反比例するのだ (:

経過を教えてくれ。何か問題があれば debug.log を送ってほしい。 それだけで何が起きたか分かることが多い。

了解した……

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ビットコインクライアントが自分自身に送金する可能性を考慮していて、 取引ログにそれを示す適切な記述を入れているのを見て嬉しく思った (:

これをやった主な理由は、取引中のネットワークトラフィックをパケット キャプチャして解析するためだ。そちらのパケット構造を知らないので、 パケットからは平文の情報がわずかに見えるだけで、ほとんどは取引詳細に 表示されているような名前やコメントだ。‘version’ や ‘reply’ のような 文字列も少しだけ流れているが、残りはかなり判読不能だ。

取引について考えるうちに、IP アドレスかビットコインアドレス以外に 識別可能な情報がまったく関わっていないことに気付いた。IP による 取引の場合、ビットコインクライアントは接続した相手の IP が本当に 意図した受取人だと信じているように見える。中間者攻撃を仕掛けて 入金を盗むのはかなり簡単だ。たとえば、同僚とこちらが同じ LAN 上で ワークステーションを使っている状況を考えてみてくれ。こちらが悪意を 持ってローカルブロードキャストドメインで ARP ポイズニングを行い、 彼のワークステーション宛のすべてのトラフィックをこちらの ワークステーションを中継させて流すこともできる。我々はどちらも 勤勉な社員ではなく、今流行りの MMORPG をプレイし、ビットコインで ゲーム内アイテムを売買するのが好きだとしよう。こちらは TCP ポート 8333 への着信を監視し、それらの接続を彼のワークステーションに 渡さずこちらの方で終端させてしまえる。やや込み入っているが、 要点を示している。このタイプの攻撃は、取引する 2 者間の経路上の どのホップでも実行できる。こちらが「Big ISP USA」の悪辣な管理者 だったら、と思えば分かるだろう。

意図した受取人のアドレスとしてネットワークアドレス（IP）の使用を 許可しないことを勧める。常にビットコインアドレスを要求し、 そちらで取引するほうが少しは安全だと思う。正しく理解できているか 分からないが、ビットコインアドレスによる取引というのは、取引を ブロックチェーンに計算して入れて、受取人にそれを「発見」してもらう だけ、という理解で合っているか？ 代替案として、ネットワークノードに 解決サービスを持たせるのも考えられる。あるビットコインアドレスの ネットワークアドレスをノード間で問い合わせ、対象ノードがオンライン であれば、そのアドレスについてネットワーク全体の合意が形成された うえで送信側のビットコインアプリケーションが直接接続する、という形だ。 ビットコインアドレスはノードの鍵に紐付いているので、送信側ノードが そのビットコインアドレスの所有を証明する方法を作ることもできる はずで、そうでなければ取引を進めない、とすることもできるはずだ。 少なくとも、IP による宛先指定方式を残すつもりなら、両者間で共有した 秘密のハッシュを照合する仕組み、つまり中間者が知り得ない情報の 照合の仕組みを入れることを勧める。とはいえ、もう暗号の仕組みが 入っていて鍵も生成されているのだから、それを利用するほうが はるかに強固な解になる。

それとも、こちらが考えすぎているのか？ ネットワーク接続は 単に取引の即時通知やコメントなどの文脈情報を送るためだけのもの なのか？ ビットコインアプリケーションは受取人の公開鍵などを 取得していると述べていたし、単純な通知に必要な以上のやり取りが ネットワークトラフィックに見えるのだが。

近いうちにまた。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ダスティン・トランメルのメール（2009年1月13日 18:40 UTC）

今のところ 24.28.79.95 だが、動的なので変わるかもしれない。 ただ、このアドレスは結構長く使えているので、こちらの DHCP クライアントが 更新に成功してアドレスを失わずに済んでいるといいのだが。ときどき 変わるが、当面はこのアドレスで大丈夫だと思う。

少なくとも 1 つ、着信 IP が同じクラス B の中で頻繁に変わり続ける ノードがある。プログラムを起動するたびに変わっているのかもしれない。 こうなるとは予想していなかった。

ここからの続きを bitcoin-list か暗号メーリングリストに CC しても 構わないか？

ちなみに、bitcoin-list は: bitcoin-list@lists.sourceforge.net 購読・解除ページ: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list アーカイブ: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

Dustin D. Trammell wrote:

Satoshi Nakamoto wrote: 90 年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された 第三者ベースのシステム（Digicash など）が 10 年以上にわたって失敗 続きだったあと、彼らはもう望みがないと見ている。今回は私の知る限り 初めて非信頼ベースのシステムを試みている、というところに気付いて くれることを願う。

うむ、それこそがこちらの目を引いた最大の特徴だった。本当の難所は、 人々に実際にビットコインを評価させ、通貨になるまで持っていくことに なるだろう。

ハルが、長期的な勝算は低くとも投資対象として見られる可能性に 言及していた。今や信頼された第三者が腰砕けになって機能を削がれて しまわない電子マネーの作り方が分かったのだから、10 年後に何らかの 形で電子マネーが使われていなければ、私は驚くだろう。

仮にすぐに離陸しなかったとしても、何らかのトークンや電子マネーを 必要とする企画を次に思いついた人が、もう使える状態になっている。 リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった閉じた系や狭い分野で始まる可能性もある。一度 立ち上がってしまえば、自動販売機に小銭を入れるくらい簡単に ウェブサイトに数セントを払えるようになるなら、応用先はいくらでもある。

有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトに IP アドレスを公開できる。 「この IP の私の優先回線に X ビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。

無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加の proof-of-work を求めたい場合は、体験版に ビットコイン料金を設定することもできる。

Satoshi

私は攻撃を 2 つの種類に分けている：

1. 通信経路上に実際にいる者にしかできない攻撃
2. インターネット上のどこからでも、誰にでもできる攻撃

タイプ 1 で危険にさらされるのは、自宅や会社の同じ LAN にいる者、 途中の ISP の管理者、受信側の LAN にいる者だ。タイプ 2 で危険に さらされるのは、自分から攻撃者になることを選べる 10 億人で、 彼らは一つの手法を開発すれば複数の被害者に対する規模の経済を得る。

IP による送金は新しい公開鍵を要求するから、そう、タイプ 1 の中間者攻撃に 対しては脆弱だ。それが気がかりなら、ビットコインアドレスへの送金には その脆弱性はない。ただし、プライバシーで小さなトレードオフがある。 たぶん人々はビットコインアドレスを SSL でないウェブサイトや署名なしの 平文メールから入手することが多くなるだろうし、そういうのはすでに DNS 汚染を通じてタイプ 1 とタイプ 2 の両方に対して脆弱だ。

一つの解は、送金時に IP とビットコインアドレスの両方を使うこと （たとえば 1.2.3.4-1Kn8iojk… のように）。受信側がビットコイン アドレスの公開鍵で新しい公開鍵に署名して、送金先が本人で間違いないことを 証明する。このシステムが本格的な業務用途で使われ始めたら、必ず実装する。 別の解は SSL を使うことだ。

今のところ、IP に送るときは受取人について他の識別情報を渡していない わけだから、その IP に応答する誰かに対して目隠しで送っていることに なるのは明白だ。

後回しにしている機能の 1 つに、ウォレットを暗号化するオプションがある。

ダスティン・トランメルのメール（2009年1月15日 00:05 UTC）

正しく理解できているか分からないが、ビットコインアドレスによる 取引というのは、取引をブロックチェーンに計算して入れて、受取人に それを「発見」してもらうだけ、という理解で合っているか？

そのとおりだ。

代替案として、ネットワークノードに解決サービスを持たせるのも 考えられる。あるビットコインアドレスのネットワークアドレスをノード間で 問い合わせ、対象ノードがオンラインであれば、そのアドレスについて ネットワーク全体の合意が形成されたうえで送信側のビットコインアプリ ケーションが直接接続する、という形だ。

ビットコインアドレスだけで済んで、IP は裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。

Satoshi

On Fri, 2009-01-16 at 03:42 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月15日 13:46 UTC）

IP による送金は新しい公開鍵を要求するから、そう、タイプ 1 の中間者攻撃に 対しては脆弱だ。それが気がかりなら、ビットコインアドレスへの送金には その脆弱性はない。ただし、プライバシーで小さなトレードオフがある。 たぶん人々はビットコインアドレスを SSL でないウェブサイトや署名なしの 平文メールから入手することが多くなるだろうし、そういうのはすでに DNS 汚染を通じてタイプ 1 とタイプ 2 の両方に対して脆弱だ。

確かにそうだが、ビットコインアドレスを使う利点は、2 人の人間が 複数の異なるチャネルでアドレスを照合できる、という点だ。 友人がこちらのウェブサイトからアドレスを取って、何か怪しいと思った場合は、 こちらに電話することも、IM で連絡を取ることも、メールすることもできて、 アドレスを照合できる。攻撃者は、こちらのアドレスを悪意あるものに 置き換えるためには、音声を含むあらゆる通信チャネルすべてで置換を 行わなければならず、これはかなり難しい。ネットワーク アドレスによる直接通信を中間者攻撃する場合には、攻撃者がアドレスを 偽装するか傍受しているので、この利点はない。友人がこちらの アドレスを同じ方法で確認することはできるが、アドレスを確認しても 状況は実質改善されないわけだ。

一つの解は、送金時に IP とビットコインアドレスの両方を使うこと （たとえば 1.2.3.4-1Kn8iojk… のように）。受信側がビットコイン アドレスの公開鍵で新しい公開鍵に署名して、送金先が本人で間違いないことを 証明する。このシステムが本格的な業務用途で使われ始めたら、必ず実装する。 別の解は SSL を使うことだ。

それは良い解だ。定期的に取引する相手なら、おそらく相手の ビットコインアドレスはすでにアドレス帳に入っているはずだ。

後回しにしている機能の 1 つに、ウォレットを暗号化するオプションがある。

この話題で思いついたことが 1 つある。システム障害が起きた場合の ビットコイン消失の可能性についてだ。アプリケーションは実行 ディレクトリ内には何もデータを保存していないようなので、おそらく レジストリやその他の場所に保存しているのだろう（まだ ProcessExplorer を 取り出して自分で確認していない）。なので、復旧に必要なすべてを システム外にバックアップできるファイルにエクスポートする機能を入れて おくのは、良いアイデアかもしれない。

ビットコインアドレスだけで済んで、IP は裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。

これは常に任意機能にできる。たとえば「自分のビットコインアドレスを ネットワークに広告する」のオン／オフを切り替えるトグルをユーザーに 持たせるのだ。ビットコインアドレスで検索してもネットワーク上で 見つからない場合は、これまでどおりトランザクションをブロック チェーンに挿入する。見つかった場合は、トランザクションのメタデータを そのネットワークアドレスに通信できる、という形だ。

今日もう 1 つ気づいたのだが、アプリケーションを閉じても ネットワークソケットをきれいに閉じていないようだ（TCP RST が 飛び始める）。優先度の低い todo に入れる項目かもしれない (:

ではまた。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

On Fri, 2009-01-16 at 03:10 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月15日 13:15 UTC）

少なくとも 1 つ、着信 IP が同じクラス B の中で頻繁に変わり続ける ノードがある。プログラムを起動するたびに変わっているのかもしれない。 こうなるとは予想していなかった。

それはこちらではないと思う。会社のビットコインアプリケーションは 静的 NAT アドレスから来ているはずだし、自宅の接続は少なくともこの 3 日間（テスト目的でその間ずっとコインを送受していた）はそちらに 伝えた IP のままだ。

ここからの続きを bitcoin-list か暗号メーリングリストに CC しても 構わないか？

うむ、問題ない。

ちなみに、bitcoin-list は: bitcoin-list@lists.sourceforge.net 購読・解除ページ: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list アーカイブ: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

今すぐ参加する、ありがたい (:

ハルが、長期的な勝算は低くとも投資対象として見られる可能性に 言及していた。今や信頼された第三者が腰砕けになって機能を削がれて しまわない電子マネーの作り方が分かったのだから、10 年後に何らかの 形で電子マネーが使われていなければ、私は驚くだろう。

うむ、こちらもあのメッセージを見ていて、ノードを急いで立ち上げた理由の 一つだった。こちらのシステムはアイドル中に他に大したことはしていないので、 ビットコインを生成しない理由がない。そして、もしいつか価値が 出れば…？ ボーナスだ！

仮にすぐに離陸しなかったとしても、何らかのトークンや電子マネーを 必要とする企画を次に思いついた人が、もう使える状態になっている。 リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった閉じた系や狭い分野で始まる可能性もある。一度 立ち上がってしまえば、自動販売機に小銭を入れるくらい簡単に ウェブサイトに数セントを払えるようになるなら、応用先はいくらでもある。

少額決済を必要とする各種サイトでも使えるようになる、というのは 理解できる。ただ、閉じた系ではなく既存のビットコインのピアグループを 利用したい場合、まず自分たちの用途を支えるのに足りるコインを生成 （か購入）しなければならない、という普及の障壁も見える。閉じた 系にはこの問題がないわけだから、明らかだ。

有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトに IP アドレスを公開できる。 「この IP の私の優先回線に X ビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。

面白い応用だ (:

無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加の proof-of-work を求めたい場合は、体験版に ビットコイン料金を設定することもできる。

これも良いアイデアだ。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ダスティン・トランメルのメール（2009年1月15日 19:14 UTC）

Dustin D. Trammell wrote:

Satoshi Nakamoto wrote: 90 年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された 第三者ベースのシステム（Digicash など）が 10 年以上にわたって失敗 続きだったあと、彼らはもう望みがないと見ている。今回は私の知る限り 初めて非信頼ベースのシステムを試みている、というところに気付いて くれることを願う。

うむ、それこそがこちらの目を引いた最大の特徴だった。本当の難所は、 人々に実際にビットコインを評価させ、通貨になるまで持っていくことに なるだろう。

今や信頼された第三者が腰砕けになって機能を削がれてしまわない電子 マネーの作り方が分かったのだから、10 年後に何らかの形で電子マネーが 使われていなければ、私は驚くだろう。

リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった狭い分野で始まる可能性もある。当初は、ほぼ無料に 近いがそうではないサービス用の proof-of-work 応用で使えるだろう。

有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトに IP アドレスを公開できる。 「この IP の私の優先回線に X ビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。

無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加の proof-of-work を求めたい場合は、体験版に ビットコイン料金を設定することもできる。

人気が出る場合に備えていくらか手に入れておく意味はあるかもしれない。 十分な数の人が同じように考えれば、それが自己実現的予言になる。 いったん立ち上がってしまえば、自動販売機に小銭を入れるくらい簡単に ウェブサイトに数セントを払えるようになるなら、応用先はいくらでもある。

Satoshi Nakamoto http://www.bitcoin.org

ダスティン・トランメルのメール（2009年1月15日 19:03 UTC）

この話題で思いついたことが 1 つある。システム障害が起きた場合の ビットコイン消失の可能性についてだ。アプリケーションは実行 ディレクトリ内には何もデータを保存していないようなので、おそらく レジストリやその他の場所に保存しているのだろう（まだ ProcessExplorer を 取り出して自分で確認していない）。なので、復旧に必要なすべてを システム外にバックアップできるファイルにエクスポートする機能を入れて おくのは、良いアイデアかもしれない。

ファイルは「%appdata%\Bitcoin」にある。バックアップ対象はこの ディレクトリだ。データはトランザクション対応のデータベース DBM に 保存されているから、クラッシュや停電が起きても失われないはずだ。

%appdata% はユーザー別のアクセス権限になっている。Firefox を はじめとする新しいプログラムは設定ファイルをそこに保存するのが普通だ。 もっとも、Microsoft が Windows のリリースごとにディレクトリ名を 変えてくる上、空白を含み、画面外まではみ出すほど長いという逆風はあるが。

今日もう 1 つ気づいたのだが、アプリケーションを閉じても ネットワークソケットをきれいに閉じていないようだ（TCP RST が 飛び始める）。優先度の低い todo に入れる項目かもしれない (:

今その対応コードを次回リリース向けに追加した。

Satoshi

サトシへ、

最初の 25.00 の送金のあとに、もう 100.00 を送ってくれたわけでは ないか？ IP ではなくビットコインアドレスを使って、会社の ビットコインアプリケーションから自宅のアプリケーションに 100.00 を 自分宛に送った。自宅のアプリケーションには 100.00 の受信が あるのだが、取引詳細には「Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv」と表示されている。これは会社の こちらのビットコインアドレスではないので、そちらのクライアントが計算した ブロックに乗ってこの送金を受け取った、ということなのか？ もしそうなら、生成したビットコインアドレスに加えて、そちらの名前を どうやって知ったのか？ こちらのアプリケーションには、名前を入れる 場所すら見当たらないのだが。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

それを受け取ったのは、君の自宅のビットコインアドレスのはずだ。 送金元が誰なのかを知る方法はないので、できることはどのアドレスで 受け取ったかを表示することくらいだ。複数のアドレスを作って、 それぞれ別の相手に渡して、ラベルを付けておけば、誰が送って きているのか分かるようになる。

それ以外の名前は教えられたものしか知らない。そこに表示されている 名前は、君のアドレス帳でそのアドレスに紐付けられた名前だ。 Address Book ボタンか、君のビットコインアドレスの右にある 「Change…」ボタンから設定したものだろう。

ダスティン・トランメルのメール（2009年1月18日 09:23 UTC）

サトシへ、

最初の 25.00 の送金のあとに、もう 100.00 を送ってくれたわけでは ないか？ IP ではなくビットコインアドレスを使って、会社の ビットコインアプリケーションから自宅のアプリケーションに 100.00 を 自分宛に送った。自宅のアプリケーションには 100.00 の受信が あるのだが、取引詳細には「Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv」と表示されている。これは会社の こちらのビットコインアドレスではないので、そちらのクライアントが計算した ブロックに乗ってこの送金を受け取った、ということなのか？ もしそうなら、生成したビットコインアドレスに加えて、そちらの名前を どうやって知ったのか？ こちらのアプリケーションには、名前を入れる 場所すら見当たらないのだが。

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月18日 11:01 UTC）

それを受け取ったのは、君の自宅のビットコインアドレスのはずだ。 送金元が誰なのかを知る方法はないので、できることはどのアドレスで 受け取ったかを表示することくらいだ。複数のアドレスを作って、 それぞれ別の相手に渡して、ラベルを付けておけば、誰が送って きているのか分かるようになる。

ああ！ それが自宅の自分のアドレスだとすら気付いていなかった、 そのとおりだ (: 自宅では複数のアドレスを作っていたので、結びつかな かったのだ。

それ以外の名前は教えられたものしか知らない。そこに表示されている 名前は、君のアドレス帳でそのアドレスに紐付けられた名前だ。 Address Book ボタンか、君のビットコインアドレスの右にある 「Change…」ボタンから設定したものだろう。

ああ、おっしゃるとおり、Change ボタンのアドレス一覧で、入金を 受けたアドレスに「Satoshi」が紐付いていた。ただ、自分で その値を設定した記憶がないのだが、これはデフォルトか何か なのか？（これは初めてアプリケーションを起動したときに自動 生成された、最初のデフォルトのアドレスだ）

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ダスティン・トランメルのメール（2009年1月18日 18:09 UTC）

On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月18日 11:01 UTC）

それを受け取ったのは、君の自宅のビットコインアドレスのはずだ。 送金元が誰なのかを知る方法はないので、できることはどのアドレスで 受け取ったかを表示することくらいだ。複数のアドレスを作って、 それぞれ別の相手に渡して、ラベルを付けておけば、誰が送って きているのか分かるようになる。

ああ！ それが自宅の自分のアドレスだとすら気付いていなかった、 そのとおりだ (: 自宅では複数のアドレスを作っていたので、結びつかな かったのだ。

それ以外の名前は教えられたものしか知らない。そこに表示されている 名前は、君のアドレス帳でそのアドレスに紐付けられた名前だ。 Address Book ボタンか、君のビットコインアドレスの右にある 「Change…」ボタンから設定したものだろう。

ああ、おっしゃるとおり、Change ボタンのアドレス一覧で、入金を 受けたアドレスに「Satoshi」が紐付いていた。ただ、自分で その値を設定した記憶がないのだが、これはデフォルトか何か なのか？（これは初めてアプリケーションを起動したときに自動 生成された、最初のデフォルトのアドレスだ）

最初のデフォルトのアドレスには、作成時に Your Address と ラベルが付く。

アドレス帳ラベルが設定されるのはすべてユーザーが手動で設定した 場所だ。自動でラベルが追加されるのは、新しいアドレスに送金した ときに空白のラベルが追加されるときだけだ。たぶん、私のアドレスだと 思って入れたラベルを、ソフトウェアが分かりにくくて間違った場所に 入れてしまったのだろう。

受信用アドレスへのラベル付けは分かりにくいが、他にどうすれば いいかも分からない。単純な用途以上に使う人なら誰でも、支払い元ごとに 受取アドレスを分けて作り、誰が支払っているのかを区別する必要がある。 この概念は現実世界にあまり類比がない。

Satoshi

On Tue, 2009-01-20 at 00:44 +0800, Satoshi Nakamoto wrote:

サトシ・ナカモトのメール（2009年1月19日 11:02 UTC）

最初のデフォルトのアドレスには、作成時に Your Address と ラベルが付く。

アドレス帳ラベルが設定されるのはすべてユーザーが手動で設定した 場所だ。自動でラベルが追加されるのは、新しいアドレスに送金した ときに空白のラベルが追加されるときだけだ。たぶん、私のアドレスだと 思って入れたラベルを、ソフトウェアが分かりにくくて間違った場所に 入れてしまったのだろう。

それなら筋が通る、たぶんそれが起きたのだろう。

受信用アドレスへのラベル付けは分かりにくいが、他にどうすれば いいかも分からない。単純な用途以上に使う人なら誰でも、支払い元ごとに 受取アドレスを分けて作り、誰が支払っているのかを区別する必要がある。 この概念は現実世界にあまり類比がない。

単に Received with: X ではなく Received with address: X と表示 されていれば理解できたと思う。とはいえ、そのアドレスにサトシと 誤ラベル付けされていたことが、最初の混乱の主な原因だったのは確かだ。 ただ、おっしゃるとおりだ。現在の金融システムで人々が慣れているもの のうち、強いて言えば PayPal で複数の受信用メールアドレスを使える くらいのものしか比較対象はない。Received payment to: X と するのはどうだろうか？

— Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

ハル・フィニーの投稿（2009年1月24日 16:48 UTC）

• スパマーのボットネットは送信課金型のメールフィルターを いとも簡単に消費し尽くしてしまうだろう もし POW トークンが有用になり、特にマネーになったとすれば、マシンが アイドル状態のままで放置されることはなくなる。ユーザーは自分の コンピューターが自分のためにお金を稼いでくれることを期待するように なる（報酬が運用コストを上回ると仮定して）。稼ぎをボットネットに 盗まれているコンピューターは、現在よりも所有者の目に付きやすくなる。 したがって、その世界ではユーザーがコンピューターの保守と ボットネット感染の駆除により真剣に取り組むようになる、と 期待してよいだろう。

POW トークンに価値があるとすればスパムを抑制するもう 1 つの要因がある: スパムから POW トークンを刈り取るために、人々が大量の偽メール アカウントを立てる動機が生まれる。実質的に、POW を回収するだけで メッセージは読まない自動化されたメールボックスで、スパマーを 「逆スパミング」することになる。偽メールボックスと実在の人間の 比率が高くなりすぎて、スパムが採算に乗らなくなる可能性がある。

このプロセスは、そもそも POW トークンの価値を確立する可能性も持って いる。ボットネットを持たないスパマーは収集者からトークンを買えるからだ。 買い戻しが起きれば一時的にはスパムが増えることになるが、それは 収集者がスパマーを食い物にする自滅的な循環を加速するだけだ。

興味深いことに、e-gold 系のシステムのうち 1 つには、すでに「ダスティング」 と呼ばれるスパムの一形態が存在する。スパマーは取引のコメント欄に スパムメッセージを入れるために、ごく少量の金（ゴールド）の塵を 送り付けるのだ。もしユーザーが受け取りに応じる最低金額を設定できる ようにする、あるいは少なくともメッセージを伴う場合の最低金額を設定 できるようにすれば、ユーザーは「スパムを受け取るためにいくらもらうか」 を自分で決められるようになる。

Satoshi Nakamoto