SPV wallet lightweight wallet for bitcoin source code scenario analysis
The full name of SPV is "Simplified Payment Verification" (simple payment verification), that is, to verify whether a transaction exists or not is confirmed, so SPV wallet literally means a wallet that can perform 'simple payment verification', but can only perform simple payment verification In fact, the wallet is not very useful, so the SPV wallet that everyone is talking about generally refers to a lightweight wallet, and it is usually synonymous with a mobile device digital wallet. There are also differences in the implementation of various SPV wallets. I will first analyze various SPV wallets from the perspective of the function of the wallet.
The wallet generally includes: creating an account, receiving and verifying transactions, initiating transactions, displaying transaction history, mining
Create an account
This process does not involve data synchronization, so both full-node wallets and SPV nodes can be easily implemented. Therefore, general SPV wallets support this function, but the performance may be different. Because creating an account involves the algorithm process of encryption and decryption, certain computing resources are required. Some SPV wallets are implemented using scripting interpretation languages such as nodejs, resulting in insufficient efficiency. It may take more than 10 seconds to create a wallet.
Receive and verify transactions
If the wallet synchronizes all block data to the local, it is easy to verify the transaction, just look up whether the transaction exists in the local data. Since it is a lightweight wallet, it must not download all block data. Because the complete block data of Bitcoin is currently dozens of gigabytes, it is impossible for a mobile device running a lightweight wallet to spend such a large amount of space for storage. At the same time, the bandwidth of the mobile device is limited, and the time and cost of downloading so much data is also high. How to solve it? There are two options:
1. Server solution, the server runs a full node wallet, and the SPV wallet allows the server to verify through the web api
2. Only pull the block header. We know that the block is composed of the block header and the block transaction data. The block header is very small, and it is only a few M in total at present.
There is only the block header, how to verify whether a transaction exists? This is verified by merkle tree. The merkleroot in the blockheader contains the merkletree of the transaction data, just need merkleroot+transaction data+partialmerklepath to verify whether a transaction exists in a certain block
Initiate transactions and display transaction history
We know that Bitcoin is a utxos system. To initiate a transaction, you must select your unspent utxo (transaction output) as input, so there is a problem, the spv wallet must collect all the unused utxos of the user. Since utxos is stored in the block transaction content, to obtain utxos, the block content must be synchronized. Therefore, in order to support initiating transactions, the spv wallet has the following solutions
1. Server solution, the server runs a full-node wallet, synchronizes blocks, and establishes an account-utxos map table. The spv wallet allows the server to initiate transactions through a simple web api. Since a private key is required to initiate transactions, in order to avoid exposure to the server Private key, you can put the part of constructing the transaction in the spv implementation, the server only provides utxos, that is, the steps are: the spv requests the appropriate utxs from the server, assembles the transaction locally, sends the assembled transaction data to the server, and the server broadcasts the transaction.
2. The spv wallet synchronizes the block data content, but it is only used temporarily. It only explains the utxos belonging to the user without actually saving it. This solves the storage space problem, but the bandwidth problem during the synchronization process has not been solved. --prune The parameter is to achieve this function
3. Spv wallet synchronization block content bandwidth solution---bloom filter ( Bloom filter)
Its working mechanism is that an address filter can be added when the spv wallet synchronizes the block content, so that the full node compares the transactions in the block with the filter before returning the block content, and only transactions that satisfy the filter will be sent back. spv node, so that the amount of data actually sent back to the spv wallet is very small. For example, you can add a pubkey (wallet address) filter, so that only transactions related to a specific address will be returned to the spv wallet, and these transactions include the wallet wants user's utxos
mining
Mining is a very resource-intensive (cpu, memory) activity. SPV is for ordinary users, and generally does not support it.
Summarize
The most ideal implementation of SPV wallet is that the server is a full node, and the SPV wallet verifies and initiates transactions through the server, queries transaction history, and performs transaction encapsulation locally, that is, signRawTransaction and user interaction. The SPV node does not need to run the bitcoin core code. Since it needs to monitor the previous transaction events, the server needs to actively notify the SPV wallet of new transactions and other events through a mechanism similar to JPush. At the same time, because the interaction is generally not too complicated, it is recommended to use the react native framework to build it, which can quickly realize the simultaneous development of ios/android, and the performance is also very good.
The second solution is: only save the block header locally, and obtain the utxos transaction history of the wallet user through the bloom filter, which requires the SPV wallet to run a complete bitcoin core
appendix
A full node that supports spv generally refers to a full node that supports pubkey (address) bloom filter