Satoshi 致 Mike Hearn：关于邮件列表访问（2009 年 4 月 19 日）

此前来信Mike Hearn→ 中本聪2009-04-18核对英文来源 ↗

是的，我想大多数 P2P 客户端都通过 UPnP 协议让路由器自动开放端口。这应该能明显提高接受连接的比例。我刚发现路由器上的 DMZ 并没有启用，虽然我一直以为已经启用了。现在已经改好了。

Yes, I believe most P2P clients use the UPnP protocol to get routers to open up the port automatically. That would probably improve the listen rate significantly. I just discovered DMZ wasn't enabled on my router, though I thought it was. That's now fixed.

有没有办法收到新版本的通知？程序会自动更新吗？还是那句话，有个邮件列表之类的东西会很好。

Is there a way to be told of new versions? Does the app auto update itself? Again, some kind of mailing list would be excellent.

过去几天，我一直在想怎样为网页实现一种实用的小额支付机制。一个关键问题是：既要完全自动，又不能轻易被滥用，把用户账户里的钱扣光。我认为，合适的办法是允许任何出示 EV SSL 证书的网站自动请求一笔小额支付。默认情况下，只要金额‘低’，浏览器就接受，并显示一个小提示，说明刚才发生了什么。网站可以根据自己的设计，以合适的方式说明内容需要付费。那些滥用机制、不遵守一些简单准则的网站，例如没有明确说明点击链接会触发支付，或者从搜索引擎直接进入的链接也扣款，就把它们的 SSL 证书列入黑名单，方式类似今天的反钓鱼过滤器。

I was thinking through how a practical micropayment implementation for the web might work in the last few days. One key issue is ensuring micropayments are fully automatic, yet can't be easily abused to drain the users account. I think the right approach would be to allow any website that presents an EV SSL cert to automatically request a micropayment, by default the browser always accepts as long as the charge is "low" and displays a small notification of what has occurred. Sites can then show that content requires payment in any way that suits their site design. Abusive sites that don't meet some simple guidelines (eg, showing unambiguously that clicking a link will trigger payment, or taking payment from direct search engine links) would simply have their SSL cert blacklisted, much like anti-phishing filters work today.

这个协议可以很简单，用 Firefox 扩展或 IE BHO 就能实现。网站托管某个静态文件（例如 protocol buffer），里面指定金额、交易说明、目标 IP，以及目标节点接受交易后浏览器要加载的 URL；用户标识符通过 URL 参数发送过去。网站随后就可以返回 cookie 和付费内容。整个过程都是自动的，只需要在地址栏里出现一个小小的硬币动画之类的提示。因此，它可以像平常浏览网页一样方便。用户的软件会对哪些支付可以自动接受设定一定限制。

The protocol could be very straightforward and implemented by a Firefox extension or an IE BHO. Some static file (eg, a protocol buffer) is hosted on the site. It specifies the charge, a transaction description, the target IP and a URL for the browser to load after the transaction was accepted by the target node, to which the user identifier is sent in a URL parameter. The site can then give back a cookie and the paywalled content. The entire process is automatic and simply results in, say, a little coin animation in the URL bar. Thus it's as convenient as regular web browsing. The users software would have some limit on what payments are automatically accepted.

这个办法的主要问题是，必须有人制定用户界面的准则，再通过黑名单执行；还必须决定哪些支付要求足够小，可以自动处理，哪些需要提示用户。这就把可信的管理方重新引入了系统。不过，用户可以在开放市场上选择这个管理方。

The main problem with this approach is that somebody has to decide what the user interface guidelines are, then enforce them via blacklisting, as well as decide what payment requirements are low enough to be automatic vs requiring a user prompt. This introduces a trusted authority back into the system. However, it's one that the user can choose in an open market.

顺便说一句，如果你还没有用 protocol buffers 处理节点间通信，我推荐你使用。我们在 Google 的各种地方都用它，它能简单、高效地解决很多版本兼容问题。

By the way, if you're not already using protocol buffers for the node-to-node traffic, I recommend them. We use them here at Google for everything, they solve a lot of versioning problems simply and efficiently.