Suggestion for enhancements to getblock [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2011-07-07T19:02:04+00:00


Summary:

In a discussion about calculating balances of arbitrary addresses on the Bitcoin blockchain, Mike Hearn explains the challenges faced by clients in determining whether broadcast transactions contain sends to addresses in their wallet. He also highlights the difficulty of knowing if offline transactions for an address were included in missed blocks. Additionally, he expresses interest in supporting a split wallet feature that allows reporting the current balance in a specific address while holding the private key elsewhere.When it comes to verifying the merkle tree, Mike mentions the efficiency of verifying the merkle branch. However, he notes that efficiency is not as crucial when verifying one or minimal blocks. When asked about using a filter to reduce the list of transactions needed after being offline, Mike expresses confusion and seeks clarification on whether the filter would be based on addresses.In a Bitcoin forum discussion, Mike Hearn suggests that appearing deep in the blockchain should serve as proof of validity. This trust is especially important for Lightweight/SPV clients, and he shares an article supporting his argument. Another forum member proposes a protocol change as an alternative solution to address the issue of trusting the blockchain for Lightweight/SPV clients. The shared link leads to a discussion on how such a protocol change could help tackle this challenge.The client aims to calculate balances for specific addresses without relying on the entire blockchain. This is intended for lightweight clients to verify dependencies recursively when receiving a transaction. While the speaker questions the use of a filter since they require all transactions pending in the last ten minutes, it is suggested that if the client only cares about transactions sending coins to them, a filter would suffice. Instead of introducing a new command, the speaker suggests using 'getblocks'. However, it is acknowledged that introducing new commands is acceptable as old clients will ignore them.In a 2011 email exchange, Mike Hearn and Dr. Andy Parkins discuss the possibility of lightweight clients calculating balances for specific addresses without the need for the entire blockchain. Hearn argues that proving a transaction is not a double spend without an index of all transactions is impossible. However, Parkins clarifies that he is solely interested in calculating balances for certain addresses and would trust a full node to return the block it believes contains a specific transaction. Hearn suggests implementing filtering to match against transactions and only relay those, allowing clients to learn about new transactions without downloading the entire memory pool.In another email thread, Andy Parkins describes a scenario where he only focuses on his wallet addresses' history and stores block headers. When a block broadcast includes a transaction sending coins to one of his addresses, he wants to request those transactions to ensure their validity and presence in blocks. However, proving the absence of double-spends without knowledge of all transactions is challenging. The linked article explains that lightweight/SPV clients currently rely on appearing deep in the chain as proof of validity. In the future, users may have to wait longer or rely on trusted nodes for safety when speeds decrease. To address the issue of requesting the current pending transaction list, the author suggests implementing suggested filtering approaches instead of downloading the entire memory pool. Probabilistic filters can be set on different nodes to reduce privacy implications.The author proposes two changes to the Bitcoin protocol to enhance lightweight client functionality. The first change involves enabling the getblocks message to accept inventory items of type MSG_TX, allowing lightweight clients to request only the block containing a specific transaction rather than the entire blockchain. The second change entails creating a special virtual block request using an all-zero hash. This virtual block would list all current pending transactions and help lightweight clients check if a transaction sending coins to their addresses is pending. These changes are believed to provide clients with functionalities similar to blockexplorer.com and bitcoincharts.com.


Updated on: 2023-08-01T02:05:44.877279+00:00