SN-10206 附来源、原文与上下文。
引用的来信Mike Hearn来源 ↗我一直在做简化支付验证的 Java 实现，希望构建一个能在 Android 手机上运行的客户端。因此，我对比特币的存储需求和可扩展性想了很多，由此产生了一些论文没有回答的问题（也许将来可以出一个新版论文，因为我认为其中一些方面已经过时了）。
I have been working on a Java implementation of the simplified payment verification, with an eye to building a client that runs on Android phones. So I've been thinking a lot about storage requirements and the scalability of BitCoin, which led to some questions that the paper did not answer (maybe there could be a new version of the paper at some point, as I think aspects of it are now out of date).
论文中的简化支付验证，设想的是你直接接收交易，就像现在没人使用的按 IP 地址发送；或者由一个节点按公钥为所有交易建立索引，你就可以像从邮件服务器下载邮件一样下载它们。
The simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server.
现在，我认为纯客户端节点应该接收完整区块，以便扫描其中属于自己的交易。它们不需要存储区块，也不需要为其建立索引。初次下载时，只需下载区块头，因为程序第一次运行之前不可能收到任何付款（0.3.18 中添加了下载区块头的命令）。从那以后，它们下载完整区块，但只保存区块头。
Instead, I think client-only nodes should receive full blocks so they can scan them for their own transactions. They don't need to store them or index them. For the initial download, they only need to download headers, since there couldn't be any payments before the first time the program was run (a header download command was added in 0.3.18). From then on, they download full blocks (but only store the headers).
纯客户端模式的代码大部分已经实现。github 上有一个包含它的功能分支，我也把补丁附在了这封邮件里。
Code for client-only mode is mostly implemented. There's a feature branch on github with it, also I'm attaching the patch to this message.
下面是关于它的更多说明：
Here's some more about it:
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗“这是我目前完成的客户端模式实现。纯客户端模式只记录区块头，不使用交易索引。它不能生成币，但仍能发送和接收交易。它还没有完全达到可供最终用户使用的程度，但这没关系，因为只要没有启用 fClient，它就完全不起作用。目前，它主要是作为文档，向重新实现纯客户端的人展示功能可以从哪里划分。
"Here's my client-mode implementation so far. Client-only mode only records block headers and doesn't use the tx index. It can't generate, but it can still send and receive transactions. It's not fully finished for use by end-users, but it doesn't matter because it's a complete no-op if fClient is not enabled. At this point it's mainly documentation showing the cut-lines for client-only re-implementers.
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗在 fClient=true 的情况下，我只测试过仅下载区块头的初次下载过程。
With fClient=true, I've only tested the header-only initial download.
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗说一点背景。CBlockIndex 包含区块头的全部信息，所以要只用区块头运行，我只需像往常一样维护 CBlockIndex 结构。nFile/nBlockPos 为空，因为完整区块没有记录到磁盘上。
A little background. CBlockIndex contains all the information of the block header, so to operate with headers only, I just maintain the CBlockIndex structure as usual. The nFile/nBlockPos are null, since the full block is not recorded on disk.
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗在不删除 blk*.dat 的情况下顺利切换客户端模式开关的代码，还没有实现。主要只需要让非客户端模式的 LoadBlockIndex 忽略区块位置为空的区块索引项。这样就会把它们作为完整区块重新下载。切换回客户端模式没有问题，它不介意完整区块已经存在。
The code to gracefully switch between client-mode on/off without deleting blk*.dat in between is not implemented yet. It would mostly be a matter of having non-client LoadBlockIndex ignore block index entries with null block pos. That would make it re-download those as full blocks. Switching back to client-mode is no problem, it doesn't mind if the full blocks are there.
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗如果初始区块下载耗时太长，我们就需要把客户端模式作为一个选项，让新用户可以快速开始运行。如果能顺利关闭客户端模式，他们以后想开始生成币时，就可以关闭客户端模式，让它下载完整区块。不过，他们最好还是直接使用 getwork 矿工程序加入矿池。
If the initial block download becomes too long, we'll want client mode as an option so new users can get running quickly. With graceful switch-off of client mode, they can later turn off client mode and have it download the full blocks if they want to start generating. They should rather just use a getwork miner to join a pool instead.
中本聪引用的旧邮件Satoshi Nakamoto来源 ↗重新实现纯客户端时，完全不需要实现 EvalScript，最多只需实现标准交易模板使用的五个操作码。”
Client-only re-implementations would not need to implement EvalScript at all, or at most just implement the five ops used by the standard transaction templates."
引用的来信Mike Hearn来源 ↗具体来说，比特币有各种魔法数字，但代码和论文都没有解释它们的来源。例如，发行达到 2100 万枚币后，通胀就会停止。这个数字一定是以某种方式得出的，但我看不出来。
Specifically, BitCoin has a variety of magic numbers and neither the code nor the paper explain where they came from. For example, the fact that inflation ceases when 21 million coins have been issued. This number must have been arrived at somehow, but I can't see how.
是有根据的估计，而且计算结果恰好是整齐的数字。我想要一个数：如果它非常流行，这个数不会太低；如果不流行，也不会太高。
Educated guess, and the maths work out to round numbers. I wanted something that would be not too low if it was very popular and not too high if it wasn't.
引用的来信Mike Hearn来源 ↗另一个是 10 分钟的目标出块时间。我理解选择它是为了让交易有时间在网络中传播。但现有的大型 P2P 网络，例如 BGP，可以在 <1 分钟内把新数据传播到全世界。
Another is the 10 minute block target. I understand this was chosen to allow transactions to propagate through the network. However existing large P2P networks like BGP can propagate new data worldwide in <1 minute.
如果传播需要 1 分钟，那么 10 分钟就是一个不错的估计。这样节点只会损失 10% 的工作量（1 分钟/10 分钟）。如果延迟浪费的 CPU 时间占比更大，可能会产生我还没想到的弱点。攻击者不会受到延迟影响，因为他在连接自己生成的区块，所以他会占优势。延迟也会让链更频繁地出现临时分叉。
If propagation is 1 minute, then 10 minutes was a good guess. Then nodes are only losing 10% of their work (1 minute/10 minutes). If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of. An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage. The chain would temporarily fork more often due to latency.
引用的来信Mike Hearn来源 ↗我感兴趣的最后一个数字，是区块大小的 500kb 限制。根据维基百科，仅 Visa 在 2009 年就处理了 620 亿笔交易。换算下来，平均每秒 2000 笔，所以峰值可能约为两倍，即每秒 4000 笔。按 10 分钟的目标出块时间，峰值时一个区块可能需要容纳 240 万笔交易，这显然装不进 500kb。这个 500kb 是一个会随着时间推移，逐渐从官方客户端中取消的临时限制，还是某种更根本的限制？
The final number I'm interested in is the 500kb limit on block sizes. According to Wikipedia, Visa alone processed 62 billion transactions in 2009. Dividing through we get an average of 2000 transactions per second, so peak rate is probably around double that at 4000 transactions/sec. With a ten minute block target, at peak a block might need to contain 2.4 million transactions, which just won't fit into 500kb. Is this 500kb a temporary limitation that will be slowly removed over time from the official client or something more fundamental?
等实际使用量更接近限制，并确认一切运行正常后，就可以逐步引入更高的上限。
A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
最终，当我们有了纯客户端实现，区块链大小就不会那么重要。在那之前，所有用户仍必须下载整条区块链才能开始使用，如果能把它控制在合理大小，就很好。
Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
在交易量非常高时，网络节点会整合，会有更多矿池挖矿和 GPU 集群，而用户会运行纯客户端。通过开发来优化并实现并行处理，它可以继续扩展。
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
无论软件目前的处理能力是多少，它都会自动按摩尔定律的速度增长，大约每年 60%。
Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.
