2010 年 6 月，中本聪在论坛直言，第二个兼容实现可能威胁网络。2011 年 4 月，他又在邮件里鼓励 Mike Hearn 继续开发 BitcoinJ。把两次发言放回各自讨论，可以看到他担心的具体问题。
许可证允许重用，验证结果必须一致
Gavin Andresen 在阅读交易脚本代码时，提到它会增加开发另一套兼容实现的难度。中本聪的回答同时谈到了节点验证结果与开源许可。
我不相信 Bitcoin 的第二个兼容实现会是个好主意。这个设计有太多部分依赖所有节点在每一步都保持同步，得到完全相同的结果，第二个实现将是网络的威胁。
MIT 许可与所有其他许可及商业用途兼容，故从许可的角度也没有重写的必要。
还要在升级时保持兼容
第二天，他补充了维护上的顾虑：升级网络时，已经要照顾旧版本；另一套实现会再增加一层需要协调的行为。
对我来说，第二个版本将是巨大的开发和维护麻烦。在升级网络的同时保持向后兼容已经够难了，再来一个版本把事情锁死就更难。
我知道，大多数开发者都不喜欢自己的软件被分叉，但在这个案例里我有实实在在的技术理由。
新增交易功能，怎样与已有节点相处？
在同一则回帖里，他也解释了预留脚本能力的用途：未来软件可以增加对交易类型的收款支持，已有节点仍能按既有脚本规则验证。这是他当时对预留交易能力的说明。
收款方对脚本做模板匹配。目前，接收方只接受两种模板：直接付款和比特币地址。未来版本可以加入更多交易类型的模板，运行该版本或更高版本的节点就能接收它们。网络中所有版本的节点都能把任何新交易验证并处理进区块，哪怕它们不知道如何解读这些交易。
他也支持面向客户端的重写
2011 年 3 月，Mike Hearn 发布采用简化支付验证（SPV）的 BitcoinJ，并将消息告诉中本聪。中本聪在 3 月 9 日的回信里直接谈到“只针对客户端需求”的重写；4 月，他再次鼓励这个项目继续开发。
这真是个好消息！只针对客户端需求，从头做一个简洁的实现，可以摆脱许多复杂性，而且也向 Java 开发者打开了大门。
我确实希望你的 BitcoinJ 能继续开发成另一个客户端实现。它给 Java 开发者提供了一个可以参与的项目，而且基础更简单，不必包揽所有功能，开发起来也更容易。当另一个客户端还在下载区块链时，等不及的新用户已经能用它了，到那时，它就能吸引足够多的用户，形成规模。
读完这几段原话
他担心节点验证结果出现分歧，也明确认可只针对客户端需求的重写。把这些发言并读，软件承担哪些验证工作、能否与既有网络保持兼容，是理解他态度的关键。BitcoinJ 当时的 SPV 定位，为这两种讨论提供了具体的上下文。