比特币(BSV)知识库：支付- 简易支付验证（Simplified Payment Verification，SPV）

Posted 2021-09-12 BSV区块链

 

简易支付验证（SPV）

比特币白皮书的第 8 章节里描述了简易支付验证（Simplified Payment Verification，简称SPV）。 它允许交易接收者仅需利用 Merkle 证明，而无需下载完整的区块链，就能证明交易发送者对其所支付的资金具有控制权。 但这并不能保证这笔资金之前没有被花费掉，将交易提交给比特币矿工才能获得这种保证。尽管如此，若这笔资金此前被花费掉了，SPV 证明也可以被当作是受法律认可的数字签名技术，从而成为欺诈行为的有力证据。

SPV 允许用户之间安全地进行点对点交易，而节点之间则形成结算层。

优点

就所需数据量而言，使用 SPV 的优势很明显：

•  一个钱包就能将所有必要的区块头存储在大约 50MB 中——这涵盖了整个区块链（截至 2020 年 1 月，每个区块 80 字节，链上大约有 620,000 个区块）。总量以每年约 4MB 的速度线性增长（网络上每挖出一个块，不管区块有多大小，它仅会增加 80 个字节）。

• 对比一下，如果不使用 SPV，想要存储整个链则将需要数百 GB 。

• Merkle 路径所需的数据大小最大为字节，其中n是一个区块中的交易总数。

如比特币白皮书第 8 章节所述：

" ... [An SPV client] only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in ...”

（“... [ SPV 客户端]只需要保留最长的工作量证明链条的区块头的拷贝，它可以不断向网络发起询问，直到它确信自己拥有最长的链条，并能够通过merkle的分支通向它被加上时间戳并纳入区块的那次交易。......”）

白皮书在第 7章节中：

" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."

（“……一个不含交易信息的区块头（Block header）大小仅有80字节。如果我们设定区块生成的速率为每10分钟一个，那么每一年产生的数据位4.2MB。（80 bytes * 6 * 24 * 365 = 4.2MB）。”）

方法

一直以来，有很多对 SPV 和点对点交易的误解。过去人们习惯让交易发出方将交易广播到所有的比特币网络节点，随后交易的接收方需要以某种方式过滤网络中的全部交易，来查找到与自己相关的特定交易（这本身就是一项极其困难的任务）。最后，即使交易的发出方将交易发给了交易接收方和其它网络节点，按照惯例，无论交易类型、金额或情况如何，接收方也都必须至少等待交易确认6次。

因此，更好的方法是让交易通过SPV 客户端直接进行点对点地交涉，然后交易通过网络节点在比特币账本上进行结算。这与使用支票相似，交易可以更快速地完成：客户将签署的支票（交易）交给商家，然后商家将支票存入银行或兑现（在链上结算交易）。当/如果商家认为当前交易的风险是可以接受的，他们就会直接交付商品或服务。

世上从来都没有绝对安全的东西，欺诈的风险永远会存在（尽管它会随着时间的递推移呈指数下降）。如果交易的商品只是一杯咖啡，那么出售咖啡的商家面临的风险肯定比出售汽车的商家面临的风险要小，因此他们的交易处理方式就会不同。如果卖一杯咖啡，商家可以使用上述的 SPV 流程，只要交易确认有效他们就认可这笔支付，随后再将交易提交到网络（如果使用MAPI，甚至只需提交给受信任的矿工）。由于这种模式，他们可以在几秒内就收到欺诈企图通知和证据，因此他们不会想自己维护整个账本，甚至不希望保留用于检查的 UTXO 设置，因为他们面临的欺诈风险与维护整个账本所需的成本并不匹配。 SPV 就像没有密码的非接触式即时支付一样，此外它的安全性也很高，因为商户可以快速收到欺诈企图的反馈。同样，商户也不想让他们的客户等待6个确认，这毫无必要，因为他们已经通过SPV确认自己收到了一笔可能有效的交易，并且交易在没有双花警报的情况下被网络接受了，这种情况下，他们是有信心能够承担一杯咖啡的风险的。

Merkle树、Merkle根、Merkle路径和Merkle证明

“Merkle 树”是计算机科学中用于验证数据的结构 - 有关更多信息，请参阅维基百科定义。

比特币区块中的“Merkle根”是在区块头中的一个哈希值，它是由这个区块中所有交易的哈希值计算得出的。

SPV 中的 “Merkle路径”指的是用户从自己的交易哈希，来一步步计算出这笔交易所在区块的 Merkle 根的数值所需的数据信息。 Merkle 路径是 Merkle 证明的一部分。

SPV 中的“ Merkle 证明”是用于证明某笔特定交易存在于特定的一个区块中（用户无需检查区块中的所有交易）。它包括“Merkle根”和“Merkle路径”。

• 要创建Merkle证明，用户（或他们的钱包）只需要交易的Merkle路径以及给定区块的区块头（80 字节）。
• 为了验证merkle证明，用户（或他们的钱包）只需要区块头组成的链（而不是整个区块本身）。也就是说，他们无需检查该区块中的全部交易，只需要确定自己拥有的所有区块的区块头副本是准确的，并使用他们自己的区块头链，连同他们想要验证的交易（或其哈希值/交易id），以及它的 Merkle 证明（有时也称为入块证明），就能够验证这笔交易是否被纳入进了一个特定的区块。

Craig Wright博士在2019 年 3 月写了一篇题为 Merkle Trees and SPV 的文章澄清了一些过去人们对 SPV 和交易验证的误解。文章中包含如下图片，显示了交易哈希值如何与区块头中的 Merkle 根相关联：

SPV 钱包

SPV 钱包是一种轻量级钱包，它使用 SPV 的机制来构建比特币交易及进行支付。

为了花费某个 UTXO，SPV 钱包的用户将把以下信息传递给收款方：

1. transaction0 – 以此 UTXO 作为输出的交易，

2. ​​​​​​​transaction0的默克尔路径

3. 包含源自 Merkle 路径的 Merkle 根的区块头（或其标识符，例如区块高度）

4. transaction1- 花费此 UTXO 的交易

用户将以如下方式验证信息的有效性：从transaction0的默克尔路径计算默克尔根。然后用户将其与区块头中指定的 Merkle 根进行比较。 如果它们相同，则用户接受链上的transaction0的内容。

离线支付

请注意如果用户在本地储存了transaction0，那么他就能够离线对transaction1进行签名，因为transaction1中的任何签名都需要来自transaction0的scriptPubKey（锁定脚本）.

---

Simplified Payment Verification

Simplified Payment Verification (SPV) is described in section 8 of the Bitcoin whitepaper. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering without downloading the full Block chain, by utilising the properties of Merkle proofs. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.

SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.

Advantages

The advantages of using SPV are clear in terms of the volume of data required:

• a wallet can store all necessary block headers in around 50MB - this covers the entire block chain (as of January 2020, with 80 bytes per block and around 620,000 blocks in the chain). The total grows linearly at around 4MB per year (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block).

• contrast this with the hundreds of gigabytes which would be required to store the entire chain, if SPV were not being used.

• The size of the data required for the merkle paths is of maximum {\\displaystyle 64log_{2}{n}}  bytes, where {\\displaystyle n}  is the total number of transaction in one block.

As explained in Section 8 of the Bitcoin whitepaper:

" ... [An SPV client] only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in ...

And in Section 7:

" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."

Approach

There have been a lot of previous misunderstandings around SPV and peer-to-peer transacting. Previously, the custom had been for the sender of the payment to just broadcast the payment to the Bitcoin network nodes. The receiver of the payment would then need to somehow filter through all of the transactions coming onto the network for specific transactions relating to them (an extremely difficult task in of itself). Even if the sender sent the transaction to the receiver as well as the network nodes, the custom had been for the receiver to always wait for the transaction to be confirmed at least 6 times whatever the transaction type, amount or situation.

The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger through the network nodes. An analogy for this is a transaction done using cheque at a much faster speed. The customer hands the the signed cheque (transaction) to the merchant, who then banks or cashes the cheque (settles the transaction on chain). When/if the merchant is satisfied according to the situational risk of the transaction, then they can hand over the goods or services.

There is no such thing as absolute security, there is always a risk against the cost of being defrauded (which decreases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant will be exposed to less risk than if the transaction is to buy a car for example, and they would behave differently. If selling a cup of coffee, they can satisfy themselves that the transaction they have received appears to be valid using the SPV process detailed above, and submit the transaction themselves to the network (or even to a trusted miner if using a Merchant API). Given that they will likely receive notification and proof of a fraud attempt within seconds, they will not want to maintain a copy of the entire ledger or even the UTXO set to check against, because the risk they face does not justify the cost. SPV is adequate just as an instant contactless payment without a pin number although arguably the security of SPV is far superior given that discovery of fraud attempts is rapid. Likewise, they will not want to detain their customer while they wait for 6 confirmations - it simply is not necessary - they have received a transaction which appears to be valid, and it has been accepted by the network without a double spend alert. This will probably be enough for them to risk the cost of the coffee.

Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs

A Merkle Tree is a structure used in computer science to validate data - see wikipedia definition for more information.

The Merkle Root in a Bitcoin block is the hash contained in the block header, which is derived from the hashes of all other transactions in the block.

A Merkle Path in SPV represents the information which the user needs to calculate the expected value for the Merkle root for a block, from their own transaction hash contained in that block. The Merkle path is used as part of of the Merkle Proof.

A Merkle Proof in SPV proves the existence of a specific transaction in a specific block (without the user needing to examine all the transactions in the Block). It includes the Merkle Root and the Merkle Path.

• To create a Merkle proof, a user (or their wallet) simply needs the Merkle path of the transaction as well as the block header for a given block (80 bytes).

• To validate a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blocks themselves). I.e. they need their own copy of the block header of each block, that they know to be accurate. Using their own block header chain, together with the transaction (or its hash/id) they want to verify, as well as its Merkle proof (also sometimes referred to as an inclusion proof), a user can verify the transaction was time stamped in a specific block, without examining every transaction in that block.

An article in March 2019 entitled Merkle Trees and SPV (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification. The article included the following diagram which shows how transaction hashes can be related to the Merkle root in a block header:

 

SPV Wallet

An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct Bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:

1. {\\displaystyle Transaction_{0}}transaction0 - the transaction that contains the UTXO as an output,
2. The Merkle path of {\\displaystyle Transaction_{0}}transaction0
3. The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
4. {\\displaystyle Transaction_{1}} transaction1 - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of {\\displaystyle Transaction_{0}} transaction0. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that {\\displaystyle Transaction_{0}} transaction0 is in the chain.

Offline Payment

Note that by storing {\\displaystyle Transaction_{0}}transaction0 locally, a user will be able to sign {\\displaystyle Transaction_{1}} transaction1 offline, as any signature on {\\displaystyle Transaction_{1}} transaction1 requires the scriptPubKey (locking script) part from {\\displaystyle Transaction_{0}}transaction0.