Published on: 2012-05-16T18:22:08+00:00
Mike Hearn and Jeff Garzik discussed an alternative solution for Bitcoin that involves implementing the original design outlined over a year ago. This design uses a new protocol command to set a Bloom filter on a connection, allowing only transactions matching that filter to appear in relayed inventory. Clients can adjust the strength of the filters to choose their preferred balance between privacy and bandwidth usage. By filtering server-side instead of downloading the entire chain and dropping irrelevant transactions, clients can gain confidence in their balance by examining the chain. The proposal covers the necessary bases for an idealized model of a client as a set of private keys.Stratized nodes have been considered useful but concerns have been raised regarding security and use cases beyond a sample conversation. The discovery process for stratized nodes is similar to normal nodes, with service nodes being explicitly chosen like IRC servers for clients. However, there are no economic motivations for running a stratized server. It is suggested that keeping each request minimal would prevent resource starvation and simplify the protocol. Additionally, it is recommended to allow history to be resolved with multiple services during data download and sorting.In an email thread between Mike Hearn and Amir Taaki, Hearn expresses his belief that the best option is to implement the original design proposed over a year ago. This design involves using a new protocol command to apply Bloom filters to connections, with only matching transactions appearing in relayed inventory. By adjusting the filters' strength, clients can choose their desired level of privacy and bandwidth usage. The filters are applied to each data block in each script, allowing selection for things like multisig outputs or outputs that don't use addresses/pubkeys to authenticate. Hearn suggests writing a BIP for this alternative protocol if someone else wants to implement it, as simple optimizations to BitcoinJ could maintain its performance.Peter reviewed a proposal from Amir and provided initial reactions. He finds the proposal cool and useful but less secure than validating an entire blockchain. Peter suggests exploring detailed use cases beyond a sample conversation to better understand the security implications. He raises concerns about discovery and how stratized servers will decide which transactions to relay/store, as well as the economic motivations for running such servers. Peter also suggests working out theoretical security/cost/value calculations for subverting or lying about transactions, NODE_STRATIZED transaction chains, and address balance requests.The proposed alternative solution involves implementing the original design outlined over a year ago using a new protocol command to set Bloom filters on connections. This change is relatively simple and allows clients to gain confidence in their balance by examining the chain. The proposal maintains compatibility with existing Bitcoin clients and can be implemented through simple optimizations to BitcoinJ. The goal of the proposal is to enhance the capabilities of the Bitcoin network without disrupting its infrastructure or user base. By utilizing the existing protocol and maintaining compatibility, the proposal aims to create a smooth transition into the new parallel system while providing benefits to both new and existing users.
Updated on: 2023-08-01T03:32:00.902364+00:00