Published on: 2012-07-24T08:16:12+00:00
In a discussion among developers on the Bitcoin mailing list, the topic of debate is combining the 'filterinit' and 'filterload' commands. These commands are used to initialize and input a serialized bloom filter table metadata and data. One developer suggests that if the 'filteradd' command does not have a compelling use case, then 'filterinit' and 'filteradd' can be dropped. The consensus is that the 'filterload' command includes all the necessary metadata required to initialize a bloom filter. However, there is a need to specify the format of how these commands arrive, particularly when a new block is found. It is suggested that input from potential users is required to determine what information they might need.The discussion also revolves around the combination of bloom filters and Simplified Payment Verification (SPV) clients. The combination is not widely used because it allows the node using the bloom filter to scan transactions and choose how much effort it wants to put into each transaction on behalf of the SPV client. A negotiation protocol would need to be specified for this to work. Despite this potential solution, it may still be too heavy for nodes and could result in overloading. In such cases, the node could simply disconnect intensive peers or refuse new connections.Another topic of discussion is the format of distributing blocks in the blockchain network. A proposal suggests using the 'invgetdatamerkleblock' command instead of the 'invgetdatablock' command. This new command includes a "merkleblock" structure that optimizes bandwidth by not re-transmitting transactions already seen in the mempool. The proposal also introduces a new command, 'getmerkletx', which returns a merkletx message for each requested transaction. Implementing this proposal could help reduce orphan blocks and spurious chain splits.Additionally, there is a discussion about the format of a project and potential user input to determine what information is necessary. One developer suggests a three-part change, including adding the 'mempool' command, syncing up nodes' mempools on startup, and changing the "block" message format. The proposed format for the "block" message aims to speed up the block propagation process and incentivize miners to upgrade.Furthermore, the discussion touches upon the needs of lightweight clients and proposes new P2P commands with associated behavior changes. These proposed commands include 'filterinit', 'filterload', 'filterclear', 'filteradd', and 'mempool'. The 'filterload' and 'filteradd' commands enable special behavior changes for 'mempool' and existing P2P commands. A lightweight client would issue the 'filterload' command, sync up with blocks, and then use the 'mempool' command to sync up to current transactions. The 'mempool' command could also be useful as a diagnostic tool, even if a bloom filter is not applied to its output.Overall, the discussions revolve around optimizing the code, streamlining protocols, improving block propagation speed, and addressing the needs of SPV clients and lightweight clients. Proposals include combining functions, specifying formats, and introducing new commands to achieve these goals. Input from potential users is considered crucial in determining the necessary information and making informed decisions.
Updated on: 2023-08-01T03:35:39.542593+00:00