Satoshi 致 Mike Hearn：首个纯客户端实现（2011年1月7日）

相关通信Mike Hearn→ 中本聪2010-12-30原文来源 ↗原信文本（含旧引文） ↗

谢谢你提供这些信息。

Thanks for the info.

关于纯客户端节点，我也得出了同样的结论，一直在做的就是这个。我快做完了……区块链下载、解析以及区块和交易验证已经完成，创建支出交易的部分也快完成了。

I reached the same conclusions about client only nodes and this is what I've been implementing. I'm nearly there ..... I have block chain download, parsing and verification of the blocks/transactions done, with creation of spend transactions almost done.

第一版基本会按你的建议来做，可能再加一项优化：只存储构造区块定位器所需的区块，按指数增大间隔来选取要保留的区块。Android 提供应用私有的本地存储，所以不必存储完整区块链，也能接收新区块……只要保存足够的信息，确保始终能够跟随最长链就行。

v1 will basically do as you propose, with the possible optimization of storing only the blocks needed to form the block locator (with the exponential thinning). As Android provides local storage that is private to the app, you don't need to store the entire block chain to be able to accept new blocks ... just enough to ensure you can always stay on the longest chain.

顺便说一句，你的代码很容易阅读，是极其宝贵的参考。为此也要谢谢你。

By the way, your code is easy to read and has been an invaluable reference. So thanks for that.

第二版我在考虑，在交易被纳入区块链之前就显示它们。做法是运行经过安全加固、严格限制访问的中继节点，在交易被接纳进内存池时向手机发送消息。Android 为每台手机提供了一条安全、低功耗的后台通道。设备离线时，消息存放在服务器端；收到消息后，手机上的应用会自动启动并处理。

In v2 I'm thinking of showing transactions before they are integrated into the block chain by running secure/locked down relay nodes that send messages to the phones when a transaction is accepted into the memory pool. Android provides a secure, low power back channel to every phone. Messages are stored server side if the device is offline and apps are automatically started on the phone to handle incoming messages.

因此，只要中继节点没有被入侵，这个系统应该就足够可信，可以把小额交易立即显示在界面中。它确实引入了一些中心化和单点故障，不过，如果中继机制停止运行或被入侵，影响也只会持续到 10 分钟后下载新区块时为止。

So as long as the relay nodes are unhacked, this system should give enough trust that low value transactions can be shown in the UI immediately. It introduces some centralization/single points of failure, but if the relay mechanism dies or is hacked, the damage only lasts for 10 minutes until the new blocks are downloaded.

确实，纯客户端程序没必要实现 EvalScript，因为如果不存储整条区块链并建立索引，就无法验证交易是否存在双重支付。我的代码会解析脚本，并依赖脚本采用标准结构，但实际上并不运行它们。

Indeed, there's no point in client-only implementations implementing EvalScript because they can't verify transactions aren't being double spent without storing and indexing the entire block chain. My code parses the scripts and then relies on them having a standard structure, but doesn't actually run them.

很想看看这个数字的推导过程。从某种意义上说，币的数量是可以任意选择的，因为使用纳比特币（nanocoin）来表示时，发行单位的数量大得近乎无限。

It'd be interesting to see the working for this. In some sense the number of coins is arbitrary as the nanocoin representation means the issuance is so huge it's practically infinite.

值得实现某种更可靠的自动更新机制，或者制定一份逐步引入这项变化的时间表。哪怕只是为了让人们在判断“比特币值不值得我投入时间和精力”时，能看到一份明确、可靠的扩容计划，也值得这样做。

It'd be worth implementing some kind of more robust auto update mechanism, or a schedule for the phase in of this, if only because when people evaluate "is BitCoin worth my time and effort" a solid plan for scaling up is good to have written down.

我担心的不是硬件本身的性能，而是随着不同版本的软件实现出现、不自动更新的节点越来越多，协议逐渐僵化。当然，以纯客户端模式运行的其他实现不会造成问题；不过，SMTP 等系统即使内置了扩展机制，事实证明也无法在全球范围内升级……实现太多，安装实例也太多了。

I'm not worried about the physical capabilities of the hardware, but more protocol ossification as the app is reimplemented and nodes which don't auto-update themselves increase in number. Client only reimplementations pose no problems of course, but other systems like SMTP have proven impossible to globally upgrade despite having extension mechanisms built in .... just too many implementations and too many installations.