交易增加时，要区分两个问题：单个区块体积受到容量上限约束，整条链的历史数据则会不断累积。中本聪谈过减少存储、轻客户端和提高处理能力，也承认节点数量与传播速度会受到影响。
旧交易，要永远全部存着吗？
2008 年的白皮书草稿已经提出，用 Merkle 树保留哈希关系，剪去旧交易数据以节省磁盘；正式版第 7 节保留了这项设想。删去的是本地保存的旧数据，区块头及其哈希关系仍然保留。
他随后计算了区块头的大小。注意：每年约 4.2 MB 只算区块头，完整交易数据另计。
当一枚币的最新交易被足够多的区块覆盖后，它之前已花费的交易就可以丢弃，以节省磁盘空间。为了在不破坏区块哈希的情况下做到这一点，交易被组织成一棵 Merkle 树并进行哈希运算 [7][2][5]，其中只有树根哈希参与区块哈希的计算。这样就可以通过剪去树的分支来压缩旧区块。内部哈希无需存储。
不含交易的区块头大约为 80 字节。假设每 10 分钟生成一个区块，则每年需要 80 字节 * 6 * 24 * 365 = 4.2MB。
普通用户，可以只保存区块头与付款证明
简化支付验证（SPV）让用户查询自己的付款是否进入了工作量证明链，减少保存和处理的数据。代价是不能像完整节点那样独立检查所有交易；白皮书明确说明，它的安全依赖诚实方掌握多数算力，也保留了商家自己运行节点的选择。
无需运行完整的网络节点，也可以验证支付。用户只需保存最长工作量证明链的区块头副本；他可以查询网络节点，直到确信自己拿到的是最长链，然后取得一条 Merkle 分支，用它将交易连接到为该交易加上时间戳的区块。他无法自行检查这笔交易，但把它连接到链上的一个位置后，就能看到已有网络节点接受了它；此后添加的区块进一步确认网络已经接受它。
经常接收付款的商家，可能仍会希望运行自己的节点，以获得更独立的安全保障和更快的验证。
完整节点的工作，由谁承担？
他预期用户与处理全网交易的节点逐渐分工，节点会向专业设备集中，并通过软件优化与并行处理提高能力。他对硬件进步也很乐观，但同时直说：负担越重，节点就会越少。以下是他当时的预期。
每个用户都是一个网络节点的现状，并非大规模阶段的预期形态。那就像每个 Usenet 用户都跑自己的 NNTP 服务器。这个设计支持让用户就只做用户。跑一个节点的负担越重，节点就会越少。那少数节点会是大型服务器集群。其余的是只做交易、不挖矿的客户端节点。
在交易量非常高时，网络节点会整合，会有更多矿池挖矿和 GPU 集群，而用户会运行纯客户端。通过开发来优化并实现并行处理，它可以继续扩展。
根据摩尔定律，我们可以预期硬件速度在 5 年后变为 10 倍，在 10 年后变为 100 倍。即使比特币以疯狂的速度普及，我也认为计算机速度的增长会超过交易数量的增长。
处理交易的成本，可以通过手续费补偿
2009 年致 Mike Hearn 的邮件还谈了经济上的办法：负担过重时，参与出块的节点可以选择只处理付费交易，由各自决定接受门槛。这里获得手续费的是出块者，单纯运行验证节点不会因此获得收入。
我预计近期不需要手续费，但如果运行节点的负担变得过重，就可以运行一种只处理附带手续费的交易的节点。节点所有者自行决定能接受的最低手续费。目前，这样的节点什么也赚不到，因为没人附带手续费；但如果足够多的节点这么做，用户附带手续费就会更快得到接受，不附带则会更慢。
还要看传播速度与网络是否正常运行
少存数据，仍需考虑传输。2010 年 12 月的邮件里，他设想纯客户端接收新区块、扫描自己的交易后只保留区块头；这仍需要下载区块。同一封邮件谈到出块间隔时，他也解释了传播延迟的风险。下文“1 分钟”和“10%”是他的假设与粗略估算。
谈到提高容量上限，他给出的前提是实际使用量接近限制，并确认网络运行正常。
如果传播需要 1 分钟，那么 10 分钟就是一个不错的估计。这样节点只会损失 10% 的工作量（1 分钟/10 分钟）。如果延迟浪费的 CPU 时间占比更大，可能会产生我还没想到的弱点。攻击者不会受到延迟影响，因为他在连接自己生成的区块，所以他会占优势。延迟也会让链更频繁地出现临时分叉。
等实际使用量更接近限制，并确认一切运行正常后，就可以逐步引入更高的上限。
读完这几段原话
中本聪的办法涉及几层：减少保存的旧数据，让轻客户端与完整节点分工，优化处理能力，并用手续费补偿出块成本。他同时留下两个约束：负担会影响有多少人运行节点，传播延迟会影响安全。提高容量仍要结合实际需求和网络表现作判断。