I posted this as a comment in a thread yesterday, and received more than one message suggesting that I make it a stand-alone post. So here goes....
The fundamental idea behind simplified payment verification (SPV) was first explained in Section 8 of the bitcoin white paper: if Alice pays Bob with a bitcoin transaction, Bob requires very little additional information from the network to verify that the transaction was included in the blockchain. Bob needs only two things: (1) he needs to know the longest chain of block headers (which requires downloading 80 bytes every ten minutes), and (2) he needs to know the path through the Merkle tree that links the transaction he received to the root hash embedded in the block header (about 320 bytes of information for a block with 1000 transactions). See this video (starting at t = 18:18) for more information.
Satoshi's SPV idea is simple and brilliant. But the details get messy when implemented in the real world. The first messy detail is how Bob actually knows that Alice sent him a bitcoin transaction in the first place. Alice could directly deliver the transaction to Bob, for example via NFC or by sending it to Bob's IP address. But today this isn't what usually happens. What happens instead is that Alice broadcasts the transaction to a few random nodes on the bitcoin network, these nodes in turn "gossip" the transaction to other nodes, et cetera, until all nodes on the network are aware of the new transaction. Alice trusts that Bob will eventually hear about the transaction though this gossip process.
This brings up the first obstacle to SPV. The only way Bob can be sure to learn of the payment is to listen to every transaction broadcast on the bitcoin network. This obviously requires a lot of data (full-node level bandwidth!), which defeats the purpose of SPV in the first place.
One way to solve this bandwidth obstacle is for Bob's wallet to register his address with a full node and ask it to forward him any transactions that pay him. Later, when his transaction is confirmed in a block, the same node can also forward Bob the Merkle branch proof he requires to verify for himself that the payment he received was confirmed in the blockchain.
Easy right? Bob can trustlessly verify that he was indeed paid with only a few SMS-text-messages worth of data. So what's the problem?
The problem is that Bob is leaking privacy information. The node that provides Bob information about his transaction knows that he (or rather the entity at his IP address) cares about these transactions. Information about which transactions Bob is interested in is valuable to certain companies/agencies and is potentially harmful to Bob if leaked.
The Bitcoin developers (e.g., Mike Hearn) came up with a clever solution to improve privacy: BIP37 Bloom filters. The idea behind BIP37 is that rather than registering Bob's addresses with a full node, Bob registers a Bloom filter with the full node instead. The Bloom filter is crafted by Bob's wallet so that all of the transactions Bob cares about get picked up by the filter, but some transactions that Bob doesn't care about also get picked up by the filter, thereby confusing the node as to which transactions are really Bob's. BIP37 allows Bob to "tune" the filter to be very private (i.e, to send Bob his transactions and LOTS of other random transactions) or highly selective (i.e., to send Bob his transactions and just a few other random transactions). We see here that there appears to be a bandwidth-versus-privacy trade-off with SPV.
I still think BIP37 is great, but history has shown that it doesn't provide as much privacy as originally intended. The privacy problem with BIP37 is subtle and is due to the fact the "addresses" are so prominent in the user experience today. Every time Bob uses bitcoin to get paid he typically specifies a new address to the payer. Hopefully, this address is only paid once, but maybe Alice decides to pay Bob a second time using the same address. And so Bob wants to constantly monitor every address his wallet has every created for new incoming transactions. This means the Bloom filters he registers with full nodes are constantly growing and changing. Due to the way BIP37 is used in practice, it is possible for a node to determine specifically which addresses are Bob's from a series of these Bloom filters. We can fix this problem somewhat, but until we fully abstract "addresses" away from the user experience and make them truly "single use," I think this will always be a bit of an issue. Tom Zander (u/ThomasZander) probably has more to say on this topic.
BRD is an example of a SPV wallet that uses BIP37.
BIP157/158 took a new approach to SPV, as part of the LN efforts, and which our own Chris Pacia (u/Chris_Pacia) has contributed to and built upon. BIP157/158 turns BIP37 on its head: rather than the SPV wallet registering a filter with a node, the node provides a filter to the SPV wallet of all the transactions it is aware of, e.g., in a given block. If the SPV wallet sees that the filter contains transactions that Bob cares about, then the SPV wallet can download the complete block from a different node. The wallet then builds the Merkle proof itself (from the downloaded block) to verify that the transaction was indeed included in the blockchain. With this technique, there is no privacy information leaked at all. But we see the bandwidth-versus-privacy trade-off once again: we've improved Bob's privacy but now his wallet is downloading complete blocks every once and a while. This obviously isn't efficient if we imagine a future with 10 GB blocks!
Neutrino is an example of a wallet that uses BIP157/158.
Lastly, I'll say something about Electrum servers, although I really haven't studied them enough to speak as an authority on this topic.
Firstly, I don't think it is correct to say "'true' SPV doesn't need a server but Electrum wallets do." All SPV wallets need a server, it's just that with a wallet like BRD a run-of-the-mill Satoshi client can act as the "server." But, remember, this is only the case because BIP37 was added to the Satoshi client! We could imagine a future where BU adds Electrum-server functionality but ABC doesn't. Now is u/jonald_fyookball's Electron Cash a "real" SPV wallet or not? The answer doesn't really matter because it's a bad question to ask in the first place. In the future, we're going to see the services offered by full nodes diverge, with perhaps some providing BIP37, some providing full Electrum features, and some doing totally new things. So this idea that Electron Cash relies on a "server" while BRD doesn't is a bad way to look at things in my opinion (they both need a server). What is important instead is the trade-offs made by the particular SPV-wallet solution (e.g., in terms of bandwidth-vs-privacy, and other trade-offs).
A second comment I'll add is that adding the features of an Electrum server to a mainstream Satoshi client would probably be controversial. Understand that there is a not-insignificant faction of people who'd love to revert even BIP37! I'd bet that Core would never in a million years add Electrum functionality, I'd be surprised if ABC would implement it, while I'd be surprised if BU wouldn't implement it, at least as an option. AFAIK, Electrum is a much greater privacy leak because SPV wallets directly ask for the Merkle branch proof they are interested in, and so it is much easier for an Electrum server to figure out which addresses belong to which users.
I hope this post was informative to some readers.
Relevant comment from Tom Zander: https://www.reddit.com/r/btc/comments/aubq4x/bitcoin_cash_spv_wallet_options/ehb7ghj/
Link to preview of Chris Pacia's Neutrino-based wallet: https://twitter.com/ChrisPacia/status/1100251375366217728?s=19
[link] [comments]
from Bitcoin - The Internet of Money https://ift.tt/2U5sJnL
No comments:
Post a Comment
We have received your message and would like to thank you for writing to us, we will reply by email as soon as possible.
Talk to you soon,
[Pakcoin Worker]
[Pakcoin Global]