ところで、もしまだ見ていなければ、フォーラムでsecp256k1のセキュリティに関する議論があります：
http://www.bitcoin.org/smf/index.php?topic=2699.0
Hal（Hal Finneyだと思いますが）
はい、彼だ。Cryptographyメーリングリストで支持的で、最初のノードの一つを運用していた。
この曲線はランダムな曲線よりも攻撃のリスクが高いと考えているようです。パフォーマンスの改善のためにsecp256k1を選んだのですか？
正直に言うと、このプロジェクトはリリース前に2年間の開発を要し、多くの課題のそれぞれにかけられる時間は限られていた。SHAとRSAの推奨サイズに関するガイダンスは見つかったが、比較的新しかったECDSAについては何も見つからなかった。RSAの推奨鍵サイズを取り、ECDSAの同等の鍵サイズに変換したが、アプリ全体が256ビットセキュリティと言えるように増やした。曲線の種類を推奨するものは見つからなかったので、ただ……一つ選んだ。鍵サイズが十分に大きければ、欠点を補えることを願っている。
当時は、ECDSAを使っても帯域幅とストレージのサイズが実用的かどうか懸念していた。RSAの巨大な鍵は論外だった。当時はストレージと帯域幅がより厳しかったように感じた。サイズがようやく実用的になりつつあるか、もうすぐそうなるだろうと感じていた。発表したとき、サイズについて他の誰も懸念しなかったことに驚いたが、彼らがいかに多くの問題を議論したかにも驚き、さらにそのすべてが私がすでに考えて解決していたことだったのにも驚いた。
結果的に、ECDSAの検証時間がより大きなボトルネックかもしれない。（私のテストでは、OpenSSLはECDSA検証に3.5msかかり、毎秒約285回の検証が可能だった）クライアント版はこの問題を回避する。
状況が進化するにつれて、フルノードを実行する必要がある人の数は、当初想像していたよりも少なくなった。処理負荷が重くなっても、少数のノードでネットワークは問題なく機能するだろう。