Published on: 2012-08-17T16:51:33+00:00
Pieter Wuille and Jeff Garzik were engaged in a discussion regarding the issue of returning an empty "inv" in the Bitcoin P2P system. Jeff suggested that it is generally better to do something unconditionally rather than generate a response under certain conditions. However, Pieter disagreed and argued that returning an empty "inv" is a strange way of replying to an empty mempool because Bitcoin P2P is not a request-response protocol and "inv" messages are only sent where there are inventory items to send.In response to Pieter's point, Jeff updated the 'mempool' branch to not return "inv" if the mempool is empty. Pieter then suggested using MSG_MEMTX instead of returning an empty "inv" to confirm the transmission of the mempool is complete. However, Jeff disagreed and suggested sending a ping(nonce) instead.The discussion also touched on the topic of message types and requests for mempool contents. It was suggested that MSG_TX is fine, but it's better to request it explicitly to allow the connecting peer to configure a bloom filter before requesting mempool contents. The limitations of mobile clients were also considered, with the agreement that support for downloading the entire mempool contents at startup should not be implemented until bloom filtering is done.The conversation further delved into the concept of returning a response unconditionally and its role in feature probing and discovery. Pieter emphasized that returning a response unconditionally has little to do with feature probing or discovery but serves as a clear indication that processing is complete for each invocation.Another aspect discussed was the implementation of a new inv_type, MSG_MEMTX, which could help with distinguishing incoming "getdata" requests. This would enable querying the right storage immediately and assist with things like DoS scoring.The conversation between Pieter and Jeff also touched on the allocation of an extra service bit for the memory pool refill command. Currently, feature discovery is enabled by checking two "version" message attributes: protocol version >= 60002 and NODE_NETWORK bit set in nServices. Pieter suggested allocating an extra service bit to allow mempool-providing services to be discovered before connecting to them.In summary, the discussion revolved around the issues of returning an empty "inv" in the Bitcoin P2P system, the use of MSG_MEMTX and ping(nonce) for confirming the transmission of the mempool, the handling of message types and requests for mempool contents, and the allocation of an extra service bit for the memory pool refill command. The aim was to find the most efficient ways to handle these aspects while considering the limitations of mobile clients and ensuring clear and reliable responses.
Updated on: 2023-08-01T03:53:02.038128+00:00