SN-10210 附来源、原文与上下文。
引用的来信Mike Hearn来源 ↗顺便说一下，如果你还没看到，论坛上有一个关于 secp256k1 安全性的讨论：
By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:
Hal（我猜是 Hal Finney）
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.
引用的来信Mike Hearn来源 ↗似乎认为这条曲线比随机曲线更容易受到攻击。我猜你选择 secp256k1，是为了提到的性能提升？
seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?
我必须承认，这个项目在发布前开发了 2 年，面对众多问题，我能花在每个问题上的时间都有限。我找到了关于 SHA 和 RSA 推荐长度的指导，却没找到 ECDSA 的，当时它还比较新。我取了 RSA 的推荐密钥长度，换算成 ECDSA 的等效密钥长度，然后又提高了一些，好让整个应用可以称为具有 256 位安全性。我没找到推荐哪种曲线类型的资料，所以就……选了一条。希望密钥长度足以弥补任何不足。
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.
当时，我担心即便使用 ECDSA，带宽和存储量是否也能达到实用程度。RSA 的巨大密钥根本不用考虑。那时候，存储和带宽似乎更紧张。我觉得这个大小要么刚刚变得可行，要么很快就会可行。我介绍它时，很惊讶其他人都不担心大小，不过我也惊讶于他们争论的问题之多，更惊讶的是，其中每一个问题我都已想过并解决了。
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.
结果看来，ECDSA 验证时间可能才是更大的瓶颈。（在我的测试中，OpenSSL 每次 ECDSA 验证耗时 3.5ms，也就是每秒大约 285 次验证。）客户端版本绕过了这个问题。
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.
