比特币源码情景分析之SPV钱包轻量级钱包
SPV的全称是“Simplified Payment Verification”（简单支付验证), 即验证一笔交易是否存在是否被确认，所以SPV钱包按字面意思是可以进行‘简单支付验证’的钱包，但是只能进行简单支付验证的钱包其实作用不大的，所以目前大家所说的SPV钱包一般泛指轻量级钱包，也通常是移动设备数字钱包的代名词。 各家SPV钱包实现上也有差异的，我先从钱包的功能角度出发来分析各种SPV钱包。
钱包一般包括：创建账号，接收并验证交易，发起交易，显示交易历史, 挖矿
创建账号
这个过程不涉及到数据同步，因而全节点钱包和SPV节点都能比较容易实现，因而一般的SPV钱包都支持这个功能，只是性能可能有所不同。因为创建账号涉及加解密的算法过程，需要一定的计算资源，有些SPV钱包使用脚本解释语言比如nodejs实现，导致效率不够，创建一个钱包可能需要10多秒
接收并验证交易
如果钱包将所有区块数据同步到本地了，验证交易很容易，只需要查找本地数据是否存在该交易即可。既然是轻量级钱包，肯定不能下载所有区块数据了。因为比特币完整区块数据目前已经几十个G，运行轻量级钱包的移动设备不可能花费这么大的空间来存储，同时移动设备带宽有限，下载这么多数据时间和费用成本也很高。那怎么解决呢？有两种方案：
1.服务器解决方案，服务器运行全节点钱包，SPV钱包通过web api让服务器验证
2.只拉取区块头（blockheader）,我们知道区块由区块头和区块交易数据构成，区块头很小的，目前总共才几M。
那只有区块头，怎么验证一个交易是否存在呢？这就要通过merkle tree来验证。blockheader里的merkleroot包含了交易数据的merkletree, 只需要merkleroot+交易数据+partialmerklepath即可验证一笔交易是否存在某个区块
发起交易和显示交易历史
我们知道比特币是utxos系统，发起交易必须选择属于你的还未花的utxo(交易输出)作为输入，这样就存在一个问题，spv钱包必须收集用户所有未用的utxos。由于utxos储存在区块交易内容里，所以要获取utxos，就必须同步区块内容。因而为了支持发起交易，spv钱包有如下几种方案
1.服务器解决方案，服务器运行全节点钱包，同步区块，并建立账号-utxos map表，spv钱包通过简单的web api让服务器帮忙发起交易，由于发起交易需要使用私钥，为了避免向服务器暴露私钥，可以将构建交易的部分放在spv实现，服务器只提供utxos，即步骤为：spv向服务器请求合适的utoxs, 本地组装交易，将组装好的交易数据发送給服务器，服务器广播交易
2.spv钱包同步区块数据内容，但是只是临时使用，只是解释出其中属于用户的utxos, 而不真正保存，这就解决存储空间问题，但是同步过程中的带宽问题还是没有解决 .--prune参数就是实现这个功能的
3. spv钱包同步区块内容带宽解决方案---bloom filter(布隆过滤器)
其工作机制是，spv钱包同步区块内容时可以增加一个地址过滤器，这样全节点在返回区块内容前，先将区块里面的交易和filter比较，只有满足filter的交易才会被发回spv节点，这样真正发回到spv钱包的数据量就非常少了.比如可以添加pubkey(钱包地址)filter,这样只有和特定地址相关的交易才会返回给spv钱包，这些交易就包含钱包想要的用户的utxos
挖矿
挖矿是一个很费资源(cpu, memory)的活，SPV是面向普通用户的，一般都不会也没法支持
总结
SPV钱包最理想的实现方案是，服务器是全节点，SPV钱包通过服务器验证和发起交易，查询交易历史，本地做交易封装，即signRawTransaction和用户交互。SPV节点不需要运行bitcoin core代码，由于需要监听先的交易事件，需要服务器通过JPush类似的机制主动通知SPV钱包新的交易等事件。同时由于交互一般不太复杂，推荐用react native框架搭建, 可以快速实现ios/android同时开发，且性能也很不错。
其次方案是：本地只保存区块头，通过bloom filter获取钱包用户的utxos交易历史, 需要SPV钱包运行完整的bitcoin core
附录
支持spv的全节点一般指支持pubkey(地址) bloom filter的全节点