简单支付验证（SPV）的概念可以追溯到2008年发布的比特币白皮书。它验证一笔交易以可扩展且高效的方式记录在区块中。 然而，SPV 有一些微妙但重要的方面经常被忽视。 本文将探讨 SPV 在即时支付、数据所有权和法律合规方面的作用。

区块中的证明

比特币白皮书第 8 章介绍了 SPV 作为比特币网络是否接受支付的验证过程。 假设验证者能够访问到区块头列表，以及一笔比特币交易的数据和该交易的Proof，并从这个Proof推断出根出现在某个区块头中，那么这就可以证明该交易确实已经被包含在区块头对应的区块中了。 这种验证被认为是“简单”的，因为整个过程只需要三条信息：

区块头列表（截至目前，该列表只有 52MB）； 交易的完整数据（对于支付给公钥哈希 P2PKH 的简单交易（脚注 1），该数据小于 400 字节）； 一个Proof（即使一个区块包含10亿笔交易，这个Proof也只有928字节）

想象一下，有一个商人鲍勃，他实时维护和更新区块头列表。 当他收到客户Alice发来的支付交易时，在获得交易的Proof后，他可以立即验证该交易是否已记录在某个区块中。 如果实施BIP-270流程，那么Bob本人（或收款人）应该负责将支付交易发送到比特币网络并获取证明。 当您拥有 SPV 客户端时，这个过程非常有效，因为商家本身就拥有简单付款验证所需的上述三项信息。

对于 Bob 来说，运行这个系统的成本远低于维护一个完整区块链的成本。 这种 SPV 验证机制在存储和带宽要求方面自然是轻量级的，因此很容易看出它如何轻松扩展。

即时付款 ( )

这可能有悖常理，但 SPV 确实可以用于立即生效的支付场景。 在这种情况下，[1]客户Alice需要向商家Bob提供两笔交易和一份Proof：一是本次支付的交易；二是本次支付的交易。 另一种是支付交易花费的交易输出，该输出所在的交易将被称为“预购交易”； 这里的证明是“预购交易”。 （注：这里的“前一笔交易”的数量实际上应该取决于这笔支付交易的所有输入来自多少个不同的交易，但在这个例子中，为了简单起见，我们假设 Alice 这笔支付的输入值来自于一个前笔交易） - 订单交易）。

请注意，此时Alice的支付交易没有Proof。

对预购交易实施简单支付验证（SPV）的动机之一是添加快速失败机制，即Bob可以在将交易发送到比特币节点之前快速自行检测到无效的支付交易。 这是因为，如果先前的交易被证明确实存在于全局分类账中，那么这就证实了爱丽丝在过去的某个时刻确实拥有这笔付款所需的资金。

事实上，简单支付验证有一个更根本的动机——验证交易的完整性：确保客户在之前的交易中提供的数据没有被篡改。 在详细解释这一点之前，我们想做一个合理的假设：数字签名具有法律约束力。 请注意，自 2000 年以来英国就是这种情况。

数字签名的有效性 ( )

假设爱丽丝想从鲍勃那里购买游戏机，她向鲍勃发送了一笔支付交易。

图：本次支付交易

当查看此支付交易时，Bob 可以确定它花费了前一笔交易的输出之一 () 并根据他的支付要求将 x 分配给他。 为了确定这笔交易的有效性，他可以将这笔交易发送到比特币节点并等待反馈，但这需要一段时间。 为了更好地服务他的客户，Bob 注意到此支付交易中有数字签名（Sig_A，PK_A）。 如果他能验证这个数字签名是有效的，并确保它来自Alice，他就可以愉快地完成支付了。 买和卖。 由于Alice的数字签名，Alice将对她的行为承担法律责任。 以此类推，我们可以想到当人们用信用卡付款时，需要签名来确认付款。 验证签名的方法是检查付款人的签名与卡背面的签名是否相同。 购买高价值物品时，可能还需要提供带照片的身份证件以协助验证。

这里隐含的假设是鲍勃可以将爱丽丝的身份与公钥相关联。 在某些情况下，例如当交易价值相当低时，这种假设可能不成立。 然而，考虑到有效即时支付的好处以及审计和税收的需要，这一假设可以通过诚信计划、经过认证的公钥（脚注 2）或任何其他激励制度或法律或监管授权来证明和合理。 可实现性。 法规可能很快就会出台，要求付款人在购买超过一定限额时提供可验证的身份证明。

一般来说，验证数字签名需要三项信息[2]：

由数字签名公钥签名的消息

我们可以看到Bob已经有了前两条信息，但是所需的签名消息不仅取决于本次支付交易，还涉及到之前的交易。

图：预排序交易

该签名消息包含前一笔交易的第一个输出，即输出值（Value）和锁定脚本（ ），该锁定脚本在支付交易的输入中被引用。 有人会说Alice可以额外只提供w和Bob来验证数字签名。 然而，Alice 无法证明从上一笔交易中提取的数据的完整性（没有被篡改），除非她能够提供完整的上一笔交易和本次交易。 证明。 Proof作为交易完整性的证明，可以告诉Bob以下两点：

锁定脚本确实需要针对特定​​公钥的数字签名（例如 P2PKH 脚本）； 锁定脚本尚未修改。

确认先前交易完整性的重要性常常被低估。 前面交易中的锁定脚本将允许 Alice 在解锁脚本中放置任意一对看起来像签名和公钥的字符串。 如果Bob只有这笔支付交易的信息，他无法判断签名的有效性和公钥的合法性。 另外，因为他不知道上一笔交易中的锁定脚本是什么，这意味着Bob不能假设比特币节点会验证这个签名。 上面的例子中没有锁定脚本，因此执行脚本时不会有验证签名的步骤。

请注意，许多数据应用程序（例如应用程序）依赖交易解锁脚本中签名和公钥的有效性来证明数据所有权或访问权限。 交易的有效性并不意味着签名的有效性，除非提供了先前的交易并且其锁定脚本表明需要来自特定公钥的签名（脚注3）。 如果Bob只要求锁定脚本和输出值，那么Alice可能会生成任意一对新的私钥和公钥，并创建与公钥对应的假P2PKH锁定脚本来隐藏自己的身份或冒充他人的身份。 然后她可以对消息进行签名，以便当 Bob 验证支付交易和伪造的锁定脚本时，生成的签名将有效。 因此，Bob 在进行签名验证之前，对之前的交易进行简单的支付验证以检查交易的完整性至关重要。

通过成功验证消息中与 Alice 身份相关的公钥的数字签名，Bob 确信 Alice 确实拥有对（数量）w 个比特币的合法控制权，并且她以数字方式批准将 x 个比特币转移给自己。 在这种情况下，Bob愿意完成交易，因为他知道Alice如果双花，将承担法律责任。 这就是 SPV 有效实现即时支付的方式。

总结

当解锁脚本中的数字签名和公钥专门用于某些场景时，前一笔交易的完整性，或者更准确地说，前一笔交易中锁定脚本的完整性就变得极其重要。 完整性证明确保解锁脚本中的数字签名和特定公钥将在比特币网络中得到有效验证。 如上所述，这种完整性证明可以通过对之前交易的简单支付验证来实现。

在上面的例子中，签名和公钥（与Alice的身份相关）被认为是Alice同意向Bob支付比特币购买商品的证据，因此Bob需要确保签名有效并且确实来自Alice。 这个概念也适用于交易中的数据所有权或数据证明，例如应用程序或通过交易对有效负载中的文档进行公证。

最后我们要强调的是，SPV不仅可以用来证明已发布交易的存在，还可以用来证明交易的完整性，而交易的完整性是指交易中任何数据的完整性。

脚注：

[1] 如果只提供交易ID来验证其存在，那么验证者需要知道交易ID来自的树的深度或原始交易，才能确认该交易的存在。 这是为了确保交易 ID 确实是树上的叶子而不是内部节点。 任何信息都可能需要验证者存储或访问一些附加信息。

[2] 为了避免重复使用经过身份验证的身份密钥，Alice 可以在 Bob 验证她的身份后从她的身份密钥派生出密钥对：例如，通过使用 BIP32 未硬化的密钥路径，或者 基于 Alice 和 Bob 之间的密钥交换来实现派生。 这是为了确保Bob能够验证支付中使用的公钥与经过认证的身份公钥之间的对应关系。

[3] 我们感谢 Volt CTO 陶小杰，之前独立发现了预购交易在验证交易中的重要性（参考文章：），并促使我们写了这篇文章。

SV是唯一遵循中本聪2008年发表的白皮书《比特币：点对点电子现金系统》中协议的区块链。