TORとI2P

6 件のメッセージ BitcoinTalk madhatter, サトシ・ナカモト, BitcoinFX, riX 2010年1月16日 — 2010年2月4日
madhatter 2010年1月16日 原文 · 個別ページ

こんにちは、

また一つアイデアを思いついた。

TORとI2Pのシードを持てるようにできたらとても良いと思う。例えば、TORネットワーク内の.onionアドレスでBTを実行できる。クライアントがBTをTORに接続し、.onionアドレスからシードして接続ピアとして使用できるだろう。(I2Pについても同様で、.i2pサービスとしてBCを実行できる)

このような形でいくつかのノードをセットアップし、トンネル情報をこのフォーラムに投稿するかもしれない。すでに多くのI2PとTORのノードを運用しているので、BCを追加するのは非常に簡単だ。

システムのプライバシーを向上させるために、BCをTORおよびI2Pと互換性のあるものにするというアイデアを支持する。つまり、車輪の再発明をする必要はないのだ。BCを強化するために使える数千ものミックスネットワークノードがすでに存在している。

よろしく!

しばらくそれについて考えていた。.onionアドレスのバックエンドサポートと接続機能を追加してから、そこから進めていきたいと思う。

.onionアドレスを作成するにはユーザーがいくつかの手順を踏まなければならないため、何かに使われている.onionアドレスはあまり多くない。TORを設定して.onionアドレスを生成し、TORを再起動し、生成されたアドレスで設定する。おそらくこれは意図的なもので、TORがファイル共有プログラムに十分に自動化された形で統合できないようにしているのだろう。

さて、Torを使って疑似匿名の暗号「Bitcoin銀行」実験をセットアップしてみた。Grin

標準の9050 socksポート「デフォルト設定」を使えばほぼ成功した。つまり、Torを通じて他のBitcoinノードへの接続は確保できた。しかし、様々な問題と複数の警告メッセージに遭遇した。

「Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via polipo or socat) instead.」

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

最終的にPrivoxyとStunnel(そちらの方が慣れているので)を使って修正した。ただし、polipoとStunnelでも可能だ。

しかし、ポート8333(Bitcoinの「デフォルト」として想定通り)と6667(間違っていなければIRCポートだ!?)について、時折警告が出る。

Tor経由でBitcoinに接続すると、Torが[scrubbed]アドレスへの「欠落した」接続を確立しようとして、繰り返し出口ノードを変更する。最初はTorの出口がポート8333や6667をブロックしているためだと思ったが、ほとんどの場合そうではなかった!

Tor経由の他のP2Pアプリケーションは、接続できないIPアドレスを「無視」でき、「警告」なしに動作を続行できる。しかし、Bitcoinはブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならない! したがって、Bitcoinノードが1つだけ稼働しているIP範囲がTor出口ノードをブロックしている場合、これは常にそうなるのだろうか?

これは多くの理由で問題がある。Huh

riX 2010年2月2日 原文 · 個別ページ

Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM

さて、Torを使って疑似匿名の暗号「Bitcoin銀行」実験をセットアップしてみた。Grin

標準の9050 socksポート「デフォルト設定」を使えばほぼ成功した。つまり、Torを通じて他のBitcoinノードへの接続は確保できた。しかし、様々な問題と複数の警告メッセージに遭遇した。

「Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via polipo or socat) instead.」

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

最終的にPrivoxyとStunnel(そちらの方が慣れているので)を使って修正した。ただし、polipoとStunnelでも可能だ。

しかし、ポート8333(Bitcoinの「デフォルト」として想定通り)と6667(間違っていなければIRCポートだ!?)について、時折警告が出る。

Tor経由でBitcoinに接続すると、Torが[scrubbed]アドレスへの「欠落した」接続を確立しようとして、繰り返し出口ノードを変更する。最初はTorの出口がポート8333や6667をブロックしているためだと思ったが、ほとんどの場合そうではなかった!

Tor経由の他のP2Pアプリケーションは、接続できないIPアドレスを「無視」でき、「警告」なしに動作を続行できる。しかし、Bitcoinはブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならない! したがって、Bitcoinノードが1つだけ稼働しているIP範囲がTor出口ノードをブロックしている場合、これは常にそうなるのだろうか?

これは多くの理由で問題がある。Huh

BitcoinはIPアドレスを使っていて、ホスト名は使っていないので、DNSは不要だ。TorはbitcoinがTorの内部DNSを通さずにIPに接続しようとしているため、通常のDNSを使っていると判断してしまう。

Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM

さて、Torを使って疑似匿名の暗号「Bitcoin銀行」実験をセットアップしてみた。Grin

標準の9050 socksポート「デフォルト設定」を使えばほぼ成功した。つまり、Torを通じて他のBitcoinノードへの接続は確保できた。しかし、様々な問題と複数の警告メッセージに遭遇した。

「Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via polipo or socat) instead.」

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

最終的にPrivoxyとStunnel(そちらの方が慣れているので)を使って修正した。ただし、polipoとStunnelでも可能だ。

しかし、ポート8333(Bitcoinの「デフォルト」として想定通り)と6667(間違っていなければIRCポートだ!?)について、時折警告が出る。

Tor経由でBitcoinに接続すると、Torが[scrubbed]アドレスへの「欠落した」接続を確立しようとして、繰り返し出口ノードを変更する。最初はTorの出口がポート8333や6667をブロックしているためだと思ったが、ほとんどの場合そうではなかった!

Tor経由の他のP2Pアプリケーションは、接続できないIPアドレスを「無視」でき、「警告」なしに動作を続行できる。しかし、Bitcoinはブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならない! したがって、Bitcoinノードが1つだけ稼働しているIP範囲がTor出口ノードをブロックしている場合、これは常にそうなるのだろうか?

これは多くの理由で問題がある。Huh

Bitcoinはポート8333を使っている。Torのポート9050を通してリレーしているとしてもだ。Tongue 6667はIRCだ。Bitcoinはノードリストの配布にIRCサーバーを使っている。(Bitcoinを動かしている別のコンピュータのIPを知っていれば、-connectオプションを指定してノードリストの使用を回避できる。)

Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM

さて、Torを使って疑似匿名の暗号「Bitcoin銀行」実験をセットアップしてみた。Grin

標準の9050 socksポート「デフォルト設定」を使えばほぼ成功した。つまり、Torを通じて他のBitcoinノードへの接続は確保できた。しかし、様々な問題と複数の警告メッセージに遭遇した。

「Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via polipo or socat) instead.」

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

最終的にPrivoxyとStunnel(そちらの方が慣れているので)を使って修正した。ただし、polipoとStunnelでも可能だ。

しかし、ポート8333(Bitcoinの「デフォルト」として想定通り)と6667(間違っていなければIRCポートだ!?)について、時折警告が出る。

Tor経由でBitcoinに接続すると、Torが[scrubbed]アドレスへの「欠落した」接続を確立しようとして、繰り返し出口ノードを変更する。最初はTorの出口がポート8333や6667をブロックしているためだと思ったが、ほとんどの場合そうではなかった!

Tor経由の他のP2Pアプリケーションは、接続できないIPアドレスを「無視」でき、「警告」なしに動作を続行できる。しかし、Bitcoinはブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならない! したがって、Bitcoinノードが1つだけ稼働しているIP範囲がTor出口ノードをブロックしている場合、これは常にそうなるのだろうか?

これは多くの理由で問題がある。Huh

いや、最長のブロックチェーンのコピーを持っている限り、たった1つのノードに接続されていれば十分だ。

了解、ありがとうriX。

つまり、Bitcoinが少なくとも1つのノードに接続されれば、-connectオプションで6667の警告を排除できるわけだ。

Bitcoinは何らかの「ピア交換」やDHTを使っているのだろうか? これでもTorの「出口」警告が止まらず、そのためTorが接続のために新しい「出口」ノードを試行し続ける必要がある問題は解決しないようだ。(これはTorにとって問題であり、Bitcoinではないが Wink)「しかし、Bitcoinはブロックの漏れがないか確認するために、すべてのノードに接続を試みなければならないのでは?」というのは本当はそういう意味だった。表現が不正確だった。

I2Pの方がBitcoinユーザーの匿名性を高める実装としてはるかに簡単な解決策に思える。 http://forum.i2p2.de/viewtopic.php?t=3946&sid=213e3cd998db98c4511675ecbba17af4

JonDonymもテストしている。http://anonymous-proxy-servers.net/ (有料サービスのみsocks対応!)ただし、paysafecardsを受け付けており、現在Bitcoinと交換で購入できる。Grin

プロキシポート9050を使用する場合、IRCサーバーがすべてのTOR出口ノードをBANしているため、おそらく常に失敗するとわかっているので、IRCへの接続は1回だけ試行し、その後諦める。別のポートを使用している場合、通常の古いプロキシである可能性があると判断し、徐々に間隔を長くしながらIRCへの再試行を続ける。PolipoやPrivoxyは使用しないでほしい。これらはHTTPフィルターおよびキャッシュであり、変更を加えるとBitcoinのメッセージを破損する可能性がある。Bitcoinは再接続によって克服しようとしているのかもしれない。ポート9050を使用してほしい。

riXが言うように、「TorにはIPアドレスしか渡していない。DNSを行うアプリは…」という警告は心配する必要はない。BitcoinはプロキシモードではまったくDNSを使用しない。

BitcoinはTor経由でIRCに接続できないため、現在どのノードがオンラインかわからず、最近確認されたすべてのノードを試す必要がある。接続試行をできるだけ節約しようとするが、起動時に素早く接続し、切断された場合に素早く再接続したいという要望もある。最後に接続に成功してからの時間が長いほど、接続試行の頻度を下げるアルゴリズムを使用している。例えば、24時間前に確認されたノードの場合、接続試行の間隔は5時間だ。少なくとも2つの接続があれば、1週間以上前のものは試行せず、5つの接続があれば24時間以上前のものは試行しない。