Published on: 2017-04-01T23:49:03+00:00
In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out.
Updated on: 2023-08-01T18:08:45.575890+00:00