Developers Introduce Bloom Filters to Improve Bitcoin Wallet Security

Bitcoin developers are always looking to add new features and improvements to the many available wallet solutions. The introduction of committed bloom filters will be a significant milestone for privacy as the BIP37 SPV solution needs to be reworked.

Committed Bloom Filters Versus BIP37 SPV

For Bitcoin users who have been embracing the lightweight client model, there are some issues associated with BIP37 SPV in its current implementation. First of all, the originally anticipated levels of privacy will not be achieved through BIP37 SPV wallet support. The probabilistic nature of bloom filters offers no privacy whatsoever, and a wrongful implementation of this technology will only make matters significantly worse.

Secondly, there are mounting concerns over the CPU usage required for Bitcoin lightweight clients, which are often used as network nodes. Moreover, this causes a DDoS risk, as clients can continuously request taxing blocks, causing the client to reprocess the same block over and over again.

But that is not all, as lightweight wallet clients using BIP37 SPV will validate outputs, which does not necessarily reflect the output has been spent today. Additionally, all BIP37 SPV lightweight wallet clients on the Bitcoin network can be DDoS’ed by other network nodes by returning “null filter results” for requests.

A solution has to be found, which may very well come in the form of committed bloom filters. These committed bloom filters can actually replace the BIP37 SPV standard as individual filters can be cached between clients rather than requiring to be recomputed. Additionally, regular nodes can complete blockchain and transaction re-scans without having the block data available on the device.

Security is of the utmost importance when suggesting newer technologies on a large scale, and a proposal is made to present bloom filters to lightweight clients through semi-trusted oracles.These oracles can range from wallet vendors to service providers, all of whom sigh the BFD – Bloom Filter Digest – for every individual block.

It is important to note this solution would prevent oracles from learning additional information about the client wallet. Moreover, clients will have additional privacy solutions at their disposal, as they can download the block data from Bitcoin nodes, NTTP, HTTP servers, or any other source providing adequate privacy.

Last but not least, changing from BIP37 SPV to committed bloom filters does not involve a hard fork, nor does it require any changes to be made to existing mining software. The only requirement is not to have coinbase transaction scriptSig included in the bloom filter itself, which should not be all that difficult to adhere to.

Source: Linux Foundation

Header image courtesy of NewsBTC


TheBitcoinNews.com – leading Bitcoin News source since 2012