Adding request/reply id in messages



Summary:

In this email conversation, Christian Bodt has proposed a bitcoin protocol improvement. The proposal suggests adding request/reply ID in all messages by creating a new "requestid" field. The idea behind this proposal is to make robust blockchain downloading easier as the download protocol relies on the other peer sending one or more "inv" responses to "getblocks" and sending the "hashContinue". However, if the other peer doesn't send a response to getblock, sends a partial response to getblocks, mixes it with some unrelated blocks inventories, or doesn't send the "hashContinue", it becomes difficult to detect and handle this misbehavior. This could cause some DoS attacks by misbehaving peers.Jeff Garzik, in his reply, suggests that stateless protocols are of great value as they are easier to implement and prove correct. Existing clients like ArtForz' half-a-node rely on this statelessness to one degree or another. Stateful protocols, however, have their own set of problems, as one must add code to help remain "synchronized" between local and remote states. Jeff Garzik also argues that Christian Bodt's listed reasons for needing this major change (stateless to stateful) do not justify the change as handling initial block download can be accomplished in a number of ways, and peer(s) may crash or return odd results. Proper handling of such cases is necessary, regardless of the presence of req/reply id's.


Updated on: 2023-06-06T04:00:46.590164+00:00