中本聪致迈克·赫恩：关于 ECDSA 曲线选择与开发历程（2011 年 1 月 10 日）
首次公开证据
打开首次公开证据顺便说一下，如果你还没看到，论坛上有一个关于 secp256k1 安全性的讨论：
http://www.bitcoin.org/smf/index.php?topic=2699.0
Hal（我猜这是哈尔·芬尼）
是的，就是他。他在密码学邮件列表上表示支持，并运行了最早的一批节点之一。
似乎认为这条曲线比随机曲线面临更高的攻击风险。我猜你选择 secp256k1 是因为提到的性能提升？
我必须承认，这个项目在发布前开发了 2 年，而我在众多问题中的每一个上只能投入有限的时间。我找到了关于 SHA 和 RSA 推荐长度的指导，却没找到关于当时还相对较新的 ECDSA 的指导。我采用了 RSA 的推荐密钥长度，并将其换算成 ECDSA 的等效密钥长度，但随后又加大了长度，这样整个应用就可以说具备 256 位安全性。我没找到任何关于曲线类型的建议，所以我就只是……选了一条。希望密钥长度足以弥补任何不足。
当时，我担心即便使用 ECDSA，带宽和存储空间需求是否也能切实可行。RSA 的巨型密钥根本不在考虑之列。那时存储和带宽似乎都更紧张。我觉得这个尺寸要么才刚刚变得可行，要么很快就会变得可行。我介绍它时，很惊讶竟然没有其他人担心尺寸，不过我也很惊讶他们争论了那么多问题，更惊讶的是其中每一个问题我都曾想到并解决过。
事实证明，ECDSA 验证时间可能才是更大的瓶颈。（在我的测试中，OpenSSL 每次 ECDSA 验证耗时 3.5ms，也就是每秒约 285 次验证）不同的客户端版本绕过了这个问题。
随着事情的发展，需要运行完整节点的人数比我最初设想的要少。如果处理负载变得很重，只有少量节点也足以让网络正常运行。
英文原文
展开英文原文
By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:
http://www.bitcoin.org/smf/index.php?topic=2699.0
Hal (i presume this is Hal Finney)
Yes, it's him. He was supportive on the Cryptography list and ran one of the first nodes.
seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?
I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues. I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new. I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security. I didn't find anything to recommend a curve type so I just... picked one. Hopefully there is enough key size to make up for any deficiency.
At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA. RSA's huge keys were out of the question. Storage and bandwidth seemed tighter back then. I felt the size was either only just becoming practical, or would be soon. When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved.
As it turns out, ECDSA verification time may be the greater bottleneck. (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second) Client versions bypass the problem.
As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy.