参考になる提案だ、ありがとう。
Quote from: madhatter on December 09, 2009, 05:34:46 AM
やあ、
まず最初に言わせてほしいのは、これは素晴らしいコンセプトだということだ。P2Pの通貨システムは長い間ずっと夢見てきたものだ。
完全に敬服し、尊敬している。
いくつか提案がある：
ビットコインのソフトウェアがピアとの接続を確立する際（クライアントTCPソケット）、クライアント側からハンドシェイク文字列を送信するようにしてほしい。現在はサーバー側（サーバーTCPソケット）がハンドシェイクを送信している。理由はもちろん匿名性だ。ISPがクライアントをポートスキャンしてこのプログラムを実行していることを検出するのはあまりにも容易だ。
ハンドシェイク時に何らかの暗号化を使用し（上記の要望に関連する）、DPI（ディープパケットインスペクション）の際にソフトウェアの正体を難読化してほしい。中国やイランのような自由でない（自由という意味での）国の人々のことを本当に考えている。
このシステムをウェブサイトに統合してインスタントサービスを提供するためのAPIが必要だ。シンプルなHTTPSの受領メカニズムがあれば大きな効果がある。クライアントが受信した支払いをすべての関連情報とともにHTTPS URLにポストし、ステータス更新を提供するようにしてほしい。また、送金メカニズムもあると良い。これにより、送金（およびバッチ送金）を自動化できる。ステータスはHTTPSの受領インターフェースを通じて返すことができるだろう。
固定ポート/ランダムポート。実行するポートをランダムに割り当てる設定を用意してほしい（非常に制限的なファイアウォールのために静的に設定できる機能も）。
UPnPサポート。クライアントが上流のルーターに自動的にポートフォワードを作成するようにしてほしい。デフォルトで有効にし、オプションメニューでオフにできるように。
*NIXシステム向けにヘッドレス（コンソールのみ）インストールをコンパイルできるようにしてほしい。また、ネットワークサービスとしてだけ実行できる機能も。制御用のtelnet接続可能なポート（あるいはUNIXソケットでも可）があれば良いだろう。
良いアイデアだ。接続を受け入れる側は、有効なハンドシェイクを受信するまで何も送信しなければよい。どのようなポートスキャンでも、自発的に身元を明かさない無反応な接続しか得られないことになる。
すべての接続をSSL化することは考えた。DPIに対してはSSL以外のものは無意味だと思う。おそらくより良い直近の解決策は、TOR経由で接続することで、これは0.2で可能になる。
0.2以降の主な課題の一つだ。
ええ、常に同じポート番号だと、他のステルス機能もかなり無意味になる。
UPnPを試してみるのが楽しみだ。ほとんどのP2PクライアントはUPnPをデフォルトで有効にしているのだろうか？
管理インターフェースの最適な構成をまだ検討中だ。コマンドラインからバックグラウンドデーモンに通信して、受信トランザクションの照会や送金の開始を行う方法がよいかもしれない。その方が自動化に適している。あるいは80以外のポートでHTTPインターフェースを提供して、ブラウザで管理する方法はどうだろうか？