Nchain will come up with a patent here afaik
New SPV is not how electrum wallets work
Topic: What is "SPV" realy talking ? (Read 379 times)
the raw block sizes are approximately 1 MB that is usually from around 950 kB to around 1.5 MB
and the block headers are fixed at 80 bytes exactly.
that is why the size of the block headers that an SPV client such as Electrum downloads is easily calculated and rises linearly with a flat line (block count * 80 = 612149 * 80 = 48,971,920 bytes)
Thank you for the exact figures, that is why I use around for that estimation. As you wrote, I should use correct words in my post, approximately, for block size. and the block headers are fixed at 80 bytes exactly.
that is why the size of the block headers that an SPV client such as Electrum downloads is easily calculated and rises linearly with a flat line (block count * 80 = 612149 * 80 = 48,971,920 bytes)
It requires around 1000 times less than Bitcoin Core in terms of storage to run it.
- a full block: 1 MG
- a block header: < 1 KB
the raw block sizes are approximately 1 MB that is usually from around 950 kB to around 1.5 MB
and the block headers are fixed at 80 bytes exactly.
that is why the size of the block headers that an SPV client such as Electrum downloads is easily calculated and rises linearly with a flat line (block count * 80 = 612149 * 80 = 48,971,920 bytes)
One more important technical specification for SPV wallet is:
It requires around 1000 times less than Bitcoin Core in terms of storage to run it. Because SPV wallet does not download the full blockchain, full blocks. What SPV wallet does is downloading the block headers.
A quick comparison:
It requires around 1000 times less than Bitcoin Core in terms of storage to run it. Because SPV wallet does not download the full blockchain, full blocks. What SPV wallet does is downloading the block headers.
A quick comparison:
- a full block: 1 MG
- a block header: < 1 KB
The SPV wallet thinks of all the possible receiving addresses it can think of (up to some arbitrary limit, usually all used plus 100) and puts them into what's called a "bloom filter", which coarsely represents the addresses (plus potentially some others).
It then sends this "bloom filter" to a 'random full node' (as you say) and starts requesting trimmed "merkle trees" from the full node.
The node sends these trimmed "merkle trees" (which represent the parts of the block that match the "bloom filter") along with the corresponding transactions for whichever blocks the SPV requests. Typically the SPV will repeat this request for every block since the wallet was created (because it's essentially impossible to have transactions before the wallet's private key was created).
The SPV wallet then can use the "merkle tree" to prove that all the transactions sent along with it were definitely included in the block.
Importantly, it does *not* prove a transaction was *not* included in the block.
This is why it wouldn't work for the lightning network. The lightning network needs to test the inverse -- was a transaction *not* included in a block.
Compact block filters allows you to test both if a transaction *was* included in a block and confirm if it *was not* included in a block. CBF also puts less burden on full nodes as well making great strides in privacy.
But compact block filters require significantly more bandwidth than bloom filters. It's a trade off. It's not nearly as much bandwidth as running a full node but it is still significantly more bandwidth than bloom filters.
While never matching CBF's privacy, it's possible make bloom filters very private. But it requires wallet developers to use them very carefully and do a lot of node disconnects and reconnects (which is vulnerable to sybil attacks). Time has shown wallet developers have done little to none of that work and tend to use bloom filters with the default settings. Which translates to basically no privacy. Some (very few) wallets do do it correctly however. So there's this question of if turning off bloom filters to prevent the bulk of insecure wallets from operating is worth hurting the minority of wallets that use them correctly.
Clearly I have a lot on my mind on this subject.
It then sends this "bloom filter" to a 'random full node' (as you say) and starts requesting trimmed "merkle trees" from the full node.
The node sends these trimmed "merkle trees" (which represent the parts of the block that match the "bloom filter") along with the corresponding transactions for whichever blocks the SPV requests. Typically the SPV will repeat this request for every block since the wallet was created (because it's essentially impossible to have transactions before the wallet's private key was created).
The SPV wallet then can use the "merkle tree" to prove that all the transactions sent along with it were definitely included in the block.
Importantly, it does *not* prove a transaction was *not* included in the block.
This is why it wouldn't work for the lightning network. The lightning network needs to test the inverse -- was a transaction *not* included in a block.
Compact block filters allows you to test both if a transaction *was* included in a block and confirm if it *was not* included in a block. CBF also puts less burden on full nodes as well making great strides in privacy.
But compact block filters require significantly more bandwidth than bloom filters. It's a trade off. It's not nearly as much bandwidth as running a full node but it is still significantly more bandwidth than bloom filters.
While never matching CBF's privacy, it's possible make bloom filters very private. But it requires wallet developers to use them very carefully and do a lot of node disconnects and reconnects (which is vulnerable to sybil attacks). Time has shown wallet developers have done little to none of that work and tend to use bloom filters with the default settings. Which translates to basically no privacy. Some (very few) wallets do do it correctly however. So there's this question of if turning off bloom filters to prevent the bulk of insecure wallets from operating is worth hurting the minority of wallets that use them correctly.
Clearly I have a lot on my mind on this subject.
For SPV wallet, it selects a full node randomly and say "hi, i want to check a specific transaction is valid or not". Then SPV wallet sends this transaction hash and its parent's hash values(from node to merkle tree root node).
The SPV node receives these data and look up the corresponding block.
If yes it is, then say to SPV wallet,"yes, it is valid".
In all, the data transferred is a group of hash.
Is it right ?
The SPV node receives these data and look up the corresponding block.
If yes it is, then say to SPV wallet,"yes, it is valid".
In all, the data transferred is a group of hash.
Is it right ?
Jump to: