サトシ ↔ ダスティン・トランメル メール
ビットコインの最初のリリースを公開する。二重支払いを防ぐためにP2Pネットワークを使う、新しい電子キャッシュシステムだ。完全に分散化されており、サーバーも中央機関もない。
ちょうどそちらの論文を読み進めているところだ。タイムスタンプサーバーの 節で新聞やUsenetに言及されていたので、もしまだ知らなければ 興味を持つかもしれないと思った。
http://www.publictimestamp.org/
ところで、私もアルファコードをワークステーションの1台で動かして いる。これまで「Generated」のメッセージが2件出ているが、 「Credit」欄は0.00のままで残高も変わっていない。これはコインが 有効になるための経過時間／成熟の要件によるものなのかな？
それでは。
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
ちょうどそちらの論文を読み進めているところだ。タイムスタンプサーバーの 節で新聞やUsenetに言及されていたので、もしまだ知らなければ 興味を持つかもしれないと思った。
http://www.publictimestamp.org/
ありがとう、これは知らなかった。見せ方がとてもしっかりしている。 もっと古いものが長らく動いていて、ハッシュをUsenetに公開している。 このサービスがUsenetを使っていないのは意外だ。もっとも、最近では 自動投稿用にUsenetへのアクセス権を取るのが少し難しいが。 雑誌や新聞にハッシュを掲載してもらえれば、そのサービスの目的（法廷での証拠利用） にはずっと有効に働くだろう。ビットコインとすべてのタイムスタンプサーバーは、 事項を定期的にブロックにまとめてチェーンへとハッシュ化していくという 基本的な機能を共有している。
ダスティン・トランメルところで、私もアルファコードをワークステーションの1台で動かして いる。これまで「Generated」のメッセージが2件出ているが、 「Credit」欄は0.00のままで残高も変わっていない。これはコインが 有効になるための経過時間／成熟の要件によるものなのかな？
そう、「Credit」の欄は成熟するまで0.00のままで、成熟すれば50.00に なる。成熟するまではCredit欄を空欄にしておいた方が、分かりやすいと思う？ 取引の詳細（行をダブルクリックしたときに表示される画面）に 仕組みの説明文を入れるべきだろう。（行をダブルクリックすると 詳細が見られることは、すぐ分かったかな？）
まだならv0.1.3に更新しておいてほしい。このバージョンで安定性が かなり上がった。
Satoshi
ありがとう、これは知らなかった。見せ方がとてもしっかりしている。 もっと古いものが長らく動いていて、ハッシュを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を動かしていた…… これから更新する。新バージョン通知か 自動更新機能があった方が良いかもしれない (:
電子マネーと暗号は、私がすごく興味を持っている二つの分野なんだ。 想像がつくと思うけど、暗号メーリングリストへの投稿を目にしてすぐに このプロジェクトに引き付けられた。フィードバックや新機能の検証など、 いつでも声をかけてくれ。喜んで協力する。
それでは。
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
まだなら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
実は ‘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月13日03:29 UTC）電子マネーと暗号は、私がすごく興味を持っている二つの分野なんだ。 想像がつくと思うけど、暗号メーリングリストへの投稿を目にしてすぐに このプロジェクトに引き付けられた。フィードバックや新機能の検証など、 いつでも声をかけてくれ。喜んで協力する。
確かに、私たちは関心が近い！
90年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された第三者に頼るシステム（Digicashなど）が10年以上も失敗続きだったあと、その人たちはもう望みがないと見ている。信頼に頼らない仕組みを試すのは、私の知る限り今回が初めてだ。その違いに気づいてもらえるといい。
ダスティン・トランメルのメール（2009年1月13日03:29 UTC）コインが成熟したら、新しい ‘credit’ トランザクションが 生成されるのかな、それとも既存のコインベーストランザクション行のCredit欄が 更新されるのかな？
既存のトランザクション行が更新される。
ダスティン・トランメルのメール（2009年1月13日03: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月13日03:49 UTC）もう1つ質問があったんだけど…… CPU性能が最も高い1つのノードがビットコインの大半を生成して保有してしまうのを、何が妨げているんだろう？ 各ノードが他のノードから独立して動作しているのなら、あるノードが 他よりも大幅に高性能だった場合、そのノードが他のノードより先に正しい解にたどり着く確率が高くなるんじゃないか？ 性能の低い ノードもときどき幸運に恵まれるかもしれないが、馬力差が大きい場合は 大半のビットコインは最も高性能なノードが生成することになると思うんだ。
これは「車が2倍速ければ必ず勝つ」というレースとは違う。1マイクロ秒以下で済むSHA-256計算で、それぞれの試行は独立に成功確率を 持つ。あるコンピューターがハッシュ衝突を見つける確率は、そのCPU性能に比例する。性能が半分のコンピューターは、コインも 半分になる。
ダスティン・トランメルのメール（2009年1月13日03:40 UTC）このまま様子を見てみる……
経過を教えてくれ。何か問題があればdebug.logを送ってほしい。 それだけで何が起きたか分かることが多い。
Satoshi
いいな、いつだったか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
ただ、このアドレスは結構長く使えているので、私の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
サトシ・ナカモトのメール（2009年1月13日07:55 UTC）90年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された第三者に頼るシステム（Digicashなど）が10年以上も失敗続きだったあと、その人たちはもう望みがないと見ている。信頼に頼らない仕組みを試すのは、私の知る限り今回が初めてだ。その違いに気づいてもらえるといい。
ああ、まさにそこが一番目を引いたところだった。本当に難しいのは、みんなにビットコインの価値を実際に認めさせて、通貨にすることなんだよね。
ハルは、勝ち目の薄い投資として見られるかもしれない、とそれとなく書いていた。十年後に電子通貨を何らかの形で使っていなかったら 驚くだろう。信頼できる第三者が怖気づいても骨抜きにされない方法が 分かった今となっては。
仮にすぐに軌道に乗らなかったとしても、何らかのトークンや電子マネーを 必要とする企画を次に思いついた人が、もう使える状態になっている。 リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった閉じた系や狭い分野で始まる可能性もある。一度 立ち上がってしまえば、自動販売機に小銭を入れるくらい簡単に ウェブサイトに数セントを払えるようになるなら、応用先はいくらでもある。
有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトにIPアドレスを公開できる。 「このIPの私の優先回線にXビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。
無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加のproof-of-workを求めたい場合は、体験版に ビットコイン料金を設定することもできる。
Satoshi
私は攻撃を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日06:05 UTC）正しく理解できているか分からないが、ビットコインアドレスによる 取引というのは、取引をブロックチェーンに計算して入れて、受取人に それを「発見」してもらうだけ、という理解で合っているかな？
そのとおりだ。
ダスティン・トランメル代替案として、ネットワークノードに解決サービスを持たせるのも 考えられる。あるビットコインアドレスのネットワークアドレスをノード間で 問い合わせ、対象ノードがオンラインであれば、そのアドレスについて ネットワーク全体の合意が形成されたうえで送信側のビットコインアプリ ケーションが直接接続する、という形だ。
ビットコインアドレスだけで済んで、IPは裏で解決される、というのが できれば嬉しい。プライバシーやサービス拒否（DoS）の問題があるかも しれない。新しい送金方式を実装する前に、設計をじっくり考えて ベストな方式かを確認する時間は十分にある。
Satoshi
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
少なくとも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
今すぐ参加するよ、ありがとう (:
サトシ・ナカモトハルは、勝ち目の薄い投資として見られるかもしれない、とそれとなく書いていた。十年後に電子通貨を何らかの形で使っていなかったら 驚くだろう。信頼できる第三者が怖気づいても骨抜きにされない方法が 分かった今となっては。
うん、私もあのメッセージを見ていて、ノードを急いで立ち上げた理由の 一つだった。私のシステムはアイドル中に他に大したことはしていないので、 ビットコインを生成しない理由がない。そして、もしいつか価値が 出れば…？ ボーナスだ！
サトシ・ナカモト仮にすぐに軌道に乗らなかったとしても、何らかのトークンや電子マネーを 必要とする企画を次に思いついた人が、もう使える状態になっている。 リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった閉じた系や狭い分野で始まる可能性もある。一度 立ち上がってしまえば、自動販売機に小銭を入れるくらい簡単に ウェブサイトに数セントを払えるようになるなら、応用先はいくらでもある。
少額決済を必要とする各種サイトでも使えるようになる、というのは 理解できる。ただ、閉じた系ではなく既存のビットコインのピアグループを 利用したい場合、まず自分たちの用途を支えるのに足りるコインを生成 （か購入）しなければならない、という普及の障壁も見える。閉じた系にはこの問題は当然ない。
サトシ・ナカモト有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトにIPアドレスを公開できる。 「このIPの私の優先回線にXビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。
面白い応用だ (:
サトシ・ナカモト無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加のproof-of-workを求めたい場合は、体験版に ビットコイン料金を設定することもできる。
これも良いアイデアだ。
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
サトシ・ナカモトのメール（2009年1月13日07:55 UTC）90年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された第三者に頼るシステム（Digicashなど）が10年以上も失敗続きだったあと、その人たちはもう望みがないと見ている。信頼に頼らない仕組みを試すのは、私の知る限り今回が初めてだ。その違いに気づいてもらえるといい。
ああ、まさにそこが一番目を引いたところだった。本当に難しいのは、みんなにビットコインの価値を実際に認めさせて、通貨にすることなんだよね。
十年後に電子通貨を何らかの形で使っていなかったら驚くだろう。 信頼できる第三者が怖気づいても骨抜きにされない方法が分かった 今となっては。
リワードポイント、寄付トークン、ゲーム内通貨、アダルトサイト向けの 少額決済といった狭い分野で始まる可能性もある。当初は、ほぼ無料に 近いがそうではないサービス用のproof-of-work応用で使えるだろう。
有料メール送信にはすでに使える。送信ダイアログはサイズを変えられて、 好きなだけ長いメッセージを入力できる。接続したときに直接送られる。 受取人は取引をダブルクリックして全文を見る。読みきれないほどのメールが 届く有名人で、それでもファンが連絡を取れる手段を残しておきたい場合、 ビットコインを設置して自分のウェブサイトにIPアドレスを公開できる。 「このIPの私の優先回線にXビットコインを送ってくれれば、自分で メッセージに目を通す」というふうに。
無料体験を提供している有料サブスクリプションサイトが、本契約を 食い合わないように追加のproof-of-workを求めたい場合は、体験版に ビットコイン料金を設定することもできる。
万が一流行った時のために、少し手に入れておくのも悪くないかもしれない。 同じように考える人が十分にいれば、それは自己実現的予言になる。 一度軌道に乗れば、ウェブサイトに数セントを、自動販売機にコインを 入れるように手軽に払えるとしたら、応用はいくらでもある。
Satoshi Nakamoto
http://www.bitcoin.org
この話題で思いついたことが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日15: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
それを受け取ったのは、君の自宅のビットコインアドレスのはずだ。 送金元が誰なのかを知る方法はないので、できることはどのアドレスで 受け取ったかを表示することくらいだ。複数のアドレスを作って、 それぞれ別の相手に渡して、ラベルを付けておけば、誰が送って きているのか分かるようになる。
ああ！ それが自宅の自分のアドレスだとすら気付いていなかった、 そのとおりだ (: 自宅では複数のアドレスを作っていたので、結びつかなかったんだ。
サトシ・ナカモトそれ以外の名前は教えられたものしか知らない。そこに表示されている 名前は、君のアドレス帳でそのアドレスに紐付けられた名前だ。Address Bookボタンか、君のビットコインアドレスの右にある 「Change…」ボタンから設定したものだろう。
ああ、そのとおりだ。Changeボタンのアドレス一覧で、入金を 受けたアドレスに「Satoshi」が紐付いていた。ただ、自分で その値を設定した記憶がないのだが、これはデフォルトか何か かな？ （これは初めてアプリケーションを起動したときに自動 生成された、最初のデフォルトのアドレスだ）
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
サトシ・ナカモトのメール（2009年1月18日17:01 UTC）それを受け取ったのは、君の自宅のビットコインアドレスのはずだ。 送金元が誰なのかを知る方法はないので、できることはどのアドレスで 受け取ったかを表示することくらいだ。複数のアドレスを作って、 それぞれ別の相手に渡して、ラベルを付けておけば、誰が送って きているのか分かるようになる。
ああ！ それが自宅の自分のアドレスだとすら気付いていなかった、 そのとおりだ (: 自宅では複数のアドレスを作っていたので、結びつかなかったんだ。
サトシ・ナカモトそれ以外の名前は教えられたものしか知らない。そこに表示されている 名前は、君のアドレス帳でそのアドレスに紐付けられた名前だ。Address Bookボタンか、君のビットコインアドレスの右にある 「Change…」ボタンから設定したものだろう。
ああ、そのとおりだ。Changeボタンのアドレス一覧で、入金を 受けたアドレスに「Satoshi」が紐付いていた。ただ、自分で その値を設定した記憶がないのだが、これはデフォルトか何か かな？ （これは初めてアプリケーションを起動したときに自動 生成された、最初のデフォルトのアドレスだ）
最初のデフォルトのアドレスには、作成時にYour Addressと
ラベルが付く。
アドレス帳ラベルが設定されるのはすべてユーザーが手動で設定した 場所だ。自動でラベルが追加されるのは、新しいアドレスに送金した ときに空白のラベルが追加されるときだけだ。たぶん、私のアドレスだと 思って入れたラベルを、ソフトウェアが分かりにくくて間違った場所に 入れてしまったのかもしれない。
受信用アドレスへのラベル付けは分かりにくいが、他にどうすれば いいかも分からない。単純な用途以上に使う人なら誰でも、支払い元ごとに 受取アドレスを分けて作り、誰が支払っているのかを区別する必要がある。 この概念は現実世界にあまり似たものがない。
Satoshi
最初のデフォルトのアドレスには、作成時に
Your Addressと ラベルが付く。アドレス帳ラベルが設定されるのはすべてユーザーが手動で設定した 場所だ。自動でラベルが追加されるのは、新しいアドレスに送金した ときに空白のラベルが追加されるときだけだ。たぶん、私のアドレスだと 思って入れたラベルを、ソフトウェアが分かりにくくて間違った場所に 入れてしまったのかもしれない。
それなら筋が通る。たぶんそれが起きたんだろう。
サトシ・ナカモト受信用アドレスへのラベル付けは分かりにくいが、他にどうすれば いいかも分からない。単純な用途以上に使う人なら誰でも、支払い元ごとに 受取アドレスを分けて作り、誰が支払っているのかを区別する必要がある。 この概念は現実世界にあまり似たものがない。
単にReceived with: XではなくReceived with address: Xと表示
されていれば理解できたと思う。とはいえ、そのアドレスにサトシと
誤ラベル付けされていたことが、最初の混乱の主な原因だったのは確かだ。
ただ、そのとおりだ。現在の金融システムで人々が慣れているものの中に、似たものは本当にない。PayPalで受信用のメールアドレスを複数使えることくらいかな。Received payment to: Xとするのはどうかな？
—
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
- スパマーのボットネットは送信ごとの支払いメールフィルターを簡単に突破できる もしPOWトークンが本当に役に立つようになり、とりわけ貨幣になったら、マシンが遊んだままになることはなくなる。ユーザーは自分のコンピューターが稼いでくれることを期待するようになる（報酬が運用コストを上回ると仮定して）。ボットネットに稼ぎを盗まれているコンピューターは、今よりも持ち主に気づかれやすくなる。だから、そういう世界では、ユーザーはもっと熱心にコンピューターを手入れし、ボットネットの感染を取り除くようになると予想できるだろう。
POWトークンに価値があるとすればスパムを抑制するもう1つの要因がある: スパムからPOWトークンを刈り取るために、人々が大量の偽メール アカウントを立てる動機が生まれる。要するに、POWを集めるだけでメッセージは読まない自動のメールボックスで、スパマーにスパムをし返すことになる。偽メールボックスと実在の人間の 比率が高くなりすぎて、スパムが採算に乗らなくなる可能性がある。
このプロセスは、そもそもPOWトークンの価値を確立する可能性も持って いる。ボットネットを持たないスパマーは収集者からトークンを買えるからだ。 買い戻しが起きれば一時的にはスパムが増えることになるが、それは 収集者がスパマーを食い物にする自滅的な循環を加速するだけだ。
興味深いことに、e-gold系のシステムのうち1つには、すでに「ダスティング」 と呼ばれるスパムの一形態が存在する。スパマーは取引のコメント欄に スパムメッセージを入れるために、ごく少量の金（ゴールド）の塵を 送り付けるのだ。もしユーザーが受け取りに応じる最低金額を設定できる ようにする、あるいは少なくともメッセージを伴う場合の最低金額を設定 できるようにすれば、ユーザーは「スパムを受け取るためにいくらもらうか」 を自分で決められるようになる。
Satoshi Nakamoto