中本聪致迈克·赫恩：邮件列表访问（2009 年 4 月 19 日）
首次公开证据
打开首次公开证据列表是：
bitcoin-list@lists.sourceforge.net
订阅/退订页面：
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
存档：
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
我总会在那里宣布新版本。自动更新，或者至少通知有新版本，绝对在计划之中。未来可能会有必要的变更，导致在你升级之前没人愿意和你通信，而旧版本中需要有代码把这一点传达给用户。在不信任任何人的背景下，这就更困难了。
你对微支付的处理方式听起来是对的。起初，默认要求许可可能是个好主意，等用户熟悉并准备好将其设为自动后再改变。不过最终目标应该是你所描述的那样：类似于使用手机，不必真正考虑每分钟的费用。
去年 Google protocol buffers 发布时我看过它，但那时我已经把所有东西都写好了。我做的是类似 Boost Serialisation 的东西。对于这个应用来说，我解析的是来自陌生人的消息，而这些人可能有极强的动机去攻击协议，因此必须尽可能基础，这样我才能逐行检查代码，让自己确信它无懈可击。很明显，二进制格式中任何不必要的自由度，都会使潜在的攻击角度成倍增加。不过，你们在公司范围内统一采用 protocol buffers 的做法确实很正确。我认为在一般情况下，你们已经找到了最佳方案。
英文原文
展开英文原文
The list is:
bitcoin-list@lists.sourceforge.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
I'll always announce new versions there. Automatic update, or at least notification of new versions, is definitely on the list. There could potentially be necessary changes in the future where nobody will want to talk to you until you upgrade, and there needs to be code in the older version to convey that to the user. This is all the harder in the context of not trusting anyone.
Your approach to micropayments sounds right. At first, it might be a good idea to default to asking permission until the user gets comfortable and is ready to set it to automatic. The end goal though should get to something like you describe, where it's similar to using your cell phone without really having to think about the per minute charges.
I looked at Google protocol buffers when they were released last year, but I had already written everything by then. What I did was something similar to Boost Serialisation. For this application, where I was parsing messages from strangers who might have extreme incentive to hack the protocol, it was necessary to make it as basic as possible so I could crawl over every line of code to convince myself it was airtight. It became clear that any unnecessary degrees of freedom in the binary format multiplied the potential angles of attack. You guys are so right though to standardize across the company on protocol buffers. I think you've got the optimal solution in the general case.