Published on: 2015-02-21T18:38:05+00:00
In an email conversation between Mike Hearn and another individual, they discuss the efficiency of querying a single node when an address in the wallet matches a block filter. Mike argues that this method is less efficient for clients in the long run, as blocks with 1500 transactions are common and Bitcoin is growing rapidly. He imagines a system 10 times larger than today's, which would result in 15,000 transactions per block. Assuming each transaction has 5 unique keys or elements, there would be 75,000 unique elements per block. With a false positive rate of 0.1%, this results in 131.63KB of extra overhead per block. Over the course of a day, this would amount to 18mb of data per day's worth of sync to pull down over the network. This amount of data may not be competitive for mobile devices even in developed countries. However, Mike argues that it doesn't matter much because anyone watching the wire close to you can still learn which transactions are yours, and anyone running a node can learn which transactions in the requested block were yours and follow the tx chain to learn which other transactions might be yours too.The conversation revolves around the efficiency of querying a single node when an address in a wallet matches the block filter. One person thinks it's efficient, while the other disagrees. The latter argues that with Bitcoin growing, there could be up to 15,000 transactions per block, each containing five unique keys/elements that might need matching. With a false-positive rate of 0.1%, this means 131.63KB per block extra overhead, which is equivalent to 18MB of data per day's worth of sync. This amount of data may not be fast enough for mobile devices and may hinder competitiveness. However, the former believes that it doesn't matter because anyone monitoring the wire close to a user knows which transactions are theirs, and running a node allows them to follow the transaction chain to figure out which other transactions might belong to them. Additionally, even if a user requests only one block from a peer, the peer knows they will eventually request more blocks since one of the transactions given was spent in that block.The discussion revolves around the efficiency of querying a single node when an address in the wallet matches the block filter, with the downside being that it relies entirely on Tor for privacy. The use of broadcasting also requires Tor for privacy in SPV clients. The conversation then moves on to receiving BIP70 payments directly and the need to query for block inclusion as an easy way to do so. A comment regarding committed bloom filters and UTXO sets is made, where the ability to verify that positive hits are correct via merkle path and false positives are not being wrongly withheld can be obtained by obtaining merkle path proof that they are not in the trie. The email concludes with a sponsored message about the BIRT iHub F-Type from Actuate and a Bitcoin-development mailing list.The conversation is focused on the topic of privacy in Bitcoin transactions. There is a discussion about the effectiveness of bloom filters and Tor against pervasive eavesdropper threat models. The speaker suggests that Bitcoin could benefit from a store-and-forward message bus with privacy and strong reliability. They mention the development of Subspace as a potential solution. The conversation also touches on the idea of wire encryption as a way to improve privacy, which the speaker sees as a more feasible option than a new PIR protocol. Overall, the conversation highlights the challenges and trade-offs involved in achieving greater privacy in Bitcoin transactions.The discussion revolves around privacy concerns for Bitcoin transactions and the use of Tor to mitigate them. The proposal is to use block bloom filters to index non-p2sh but non-simple transactions containing checksig, while still keeping the address visible. However, there are technical issues with this proposal as Bloom filtering protocol already does this server-side. Additionally, downloading per-block Bloom filter and testing against thousands of transactions in each block will not be efficient. Furthermore, a node round-trip for every block traversal must occur if the user cannot scan the chain in parallel. This latency kills performance, making it a non-starter. Although it is possible to work around this issue by ignoring OP_CHECKSIG outputs, this method does not solve any real problems. There are concerns about commercial fraudsters stealing money, but collecting Bloom filters off the wire does not help with this. Spies such as NSA/GCHQ are building databases of IP addresses to Bitcoin addresses, but requesting data from different nodes via Tor does not solve this problem either.Using Tor presents several practical issues, including booting up slowly without a warm consensus, Bitcoin Core's DoS strategy blocking all of Tor, trolls tampering with wire traffic, and the uncertainty of relying on Tor sticking around. A simpler solution would be to add opportunistic encryption to the wire protocol.
Updated on: 2023-08-01T11:50:24.140601+00:00