Published on: 2014-06-11T08:57:29+00:00
In an email conversation, the author responds to a proposal for retroactively making Bloom filtering an optional part of the Bitcoin protocol. They argue that there is no evidence of a problem and implementing such a change would be a waste of time and resources. Instead, they suggest exploring alternatives such as block ranges in addr announcements or a new protocol optimized for serving the chain to better support archival nodes.The author also refutes the idea that a feature using resources for a legitimate reason should be classified as a Denial-of-Service (DoS) attack. They criticize attempts to reclassify any feature as an "attack" without justification, calling it silly.The article discusses how disk activity affects the performance of Bitcoin transactions. When nodes act as archival data sources, the page cache pressure is immense, causing disks to constantly run and impacting all clients. The author argues that NODE_BLOOM tends to be slower due to the working set almost always being larger than available page cache, leading to disk activity and delays. They also mention that prefix filtering may not save disk seeks and can even worsen the issue. However, prefix filtering requires additional disk space for per-block indexes, potentially slowing down block relay and increasing pressure on the page cache.It is suggested that resources such as disk I/O are not currently scarce, so it's more beneficial to focus on increasing usage rather than worrying about these resources. The article emphasizes the importance of avoiding hitting the disk, as once that happens, performance is already compromised.The conversation between Mike Hearn and Jeff Garzik revolves around the potential impact of privacy-focused bloom filters on the Bitcoin network. Mike argues that sending different bloom filters to different peers for privacy reasons would create an O(n) cost per query, greatly increasing the network load and resembling a DoS attack. He suggests that prefix filtering might be a better approach, but Jeff counters that it can cause pagecache pressure and disk activity issues. They both agree that there isn't a one-size-fits-all implementation for filters and that NODE_BLOOM should be used to advertise services with different tradeoffs. They also note the need for an upgrade to allow nodes to advertise ranges of blocks to address pagecache pressure.The article mentions that a NODE_BLOOM service bit is a reasonable way to implement bloom filters, with nodes without support for bloom filters using it as default. It is suggested that Bitcoinj is the only large-scale user of filtering, and peers advertising a lower protocol version than 70000 should disconnect themselves if they claim support for it but do not actually implement it.The conversation discusses the implementation of bloom filters for privacy reasons in the Bitcoin network. The writer explains that implementing this feature would be costly and resemble a denial-of-service attack due to the O(n) cost per query. Another person suggests that prefix filtering may not save disk seeks or could make the issue worse given the current network loads. The article argues that it's more important to focus on increasing usage rather than worrying about resources that are not currently scarce. It also suggests that bloom filters will eventually be replaced in the future.Mike Hearn and Peter Todd discuss the use of bloom filters in Bitcoin transactions. Mike argues that sending different bloom filters to different peers makes subsetting not unique to prefix filters. However, Peter explains that doing so would incur significant disk IO resource costs and that prefix filters provide a better alternative.In an email exchange, Gregory Maxwell and Peter Todd discuss the issue of data privacy in the blockchain. Todd suggests giving peers multiple prefixes corresponding to at least one address in a wallet with some false positive rate, instead of using brute-force prefix selection. Maxwell expresses surprise at using super public data in the same way as data shared between nodes. The conversation then turns to communication, with Todd suggesting the need to effectively communicate his arguments. The usefulness of prefix filtering for DH-private outputs is questioned, expressing concerns about prior information leaks becoming compromising in retrospect.Gregory Maxwell and Peter Todd discuss the privacy of blockchain data. They compare bloom filters and prefix filters used for transactions, noting their scaling differences. However, without brute forcing, prefix filters do not provide additional transactional graph privacy compared to bloom filters. The difference between super public data and data shared between trusted peers is also raised, questioning the assertion that they have "no different" privacy implications. Todd explains the concept of giving peers multiple prefixes with false positive rates corresponding to wallet addresses. He mentions having detailed this in a previous writeup on blockchain data privacy.In their conversation, Adam Back responds to a discussion on NODE_BLOOM and mentions that prefix brute forcing saves some resources but weakens privacy by providing an extra correlation hook. Peter Todd clarifies that both bloom filters and prefix filters are ways of providing a probabilistic filter for peer matching. Prefix filters have better scalability and compatibility with future miner committed indexes. They also offer better protection against hostile nodes by splitting queries across multiple peers.
Updated on: 2023-08-01T09:28:33.120863+00:00