2010 年底，Mike Hearn 正在用 Java 开发简化支付验证，目标之一是让客户端运行在 Android 手机上。他向中本聪询问存储和扩展问题。这几封回信没有给所有手机钱包规定一种做法，却清楚展示了当时的一条思路：普通收付款用户，可以不承担与完整节点相同的数据保存工作。
怎样取得自己的交易，他还在调整方案
白皮书第 8 节介绍了简化支付验证：用户可以借助区块头和交易被纳入区块的证明，核对一笔付款，而不必像完整节点那样掌握全部交易。区块头是每个区块的简要信息，包含用于连接和验证工作量证明的字段。
2010 年 12 月 29 日，中本聪回顾此前的设想：交易可以直接发给收款人，也可以由其他节点建立索引，供客户端取得。他接着提出了另一个收取交易的办法。这说明轻客户端怎样获取数据，当时仍在设计和实现中。
或者由一个节点按公钥为所有交易建立索引，你就可以像从邮件服务器下载邮件一样下载它们。
少保存区块，不等于完全不用下载区块
他在这封信中建议，客户端接收完整区块，从中查找属于自己的交易，随后只保留区块头。这样，接收并检查数据与长期保存全部数据，就可以分别处理。
初次启动时，他设想只下载区块头；这一推理针对的是开始接收付款的新客户端。如果是在恢复曾经收过款的旧钱包，就还需要寻找过去的交易，不能直接套用“第一次运行前没有付款”的前提。这也是阅读这段历史方案时需要保留的条件。
现在，我认为纯客户端节点应该接收完整区块，以便扫描其中属于自己的交易。它们不需要存储区块，也不需要为其建立索引。
保存得更少，也有验证上的边界
2011 年 3 月，两人进一步讨论尚未进入区块的付款，也就是零确认交易。中本聪指出，掌握完整交易索引的节点，可以检查交易依赖，并判断自己是否已经见过另一笔花费同一笔钱的交易。
缺少这些数据的客户端，需要参考其他节点的判断。他提出可以连接多个节点来分散这种依赖，但并没有因此保证付款一定安全。尤其要区分：某个节点还没见过冲突交易，并不代表冲突绝不可能发生。
如果不知道所有现存的交易，我不知道该如何做到第 2) 点。对此，你只能依靠信任其他节点。这种信任可以分散到多个节点。
他希望新用户能更快开始使用
到 2011 年 4 月，中本聪仍希望 Hearn 的 BitcoinJ 继续发展为另一种客户端实现。它可以让 Java 开发者参与，也可以把重点放在用户收付款所需的功能上。
他特别提到一个很具体的使用体验：当一个客户端仍在下载区块链时，用户已经能通过另一个客户端开始使用。这里讨论的是当时的设计方向与开发项目，不能据此概括今天所有手机钱包的架构。
我确实希望你的 BitcoinJ 能继续开发成另一个客户端实现。它给 Java 开发者提供了一个可以参与的项目，而且基础更简单，不必包揽所有功能，开发起来也更容易。
读完这几段原话
这些回信说明，中本聪很早就在考虑让普通用户以更少的存储负担参与比特币。具体到他当时提出的方案，客户端仍会下载和扫描区块，只是不长期保存全部区块；对零确认交易，也需要更多依赖其他节点。便利性与验证能力，要放在同一个方案里一起理解。