Published on: 2012-04-13T06:30:49+00:00
Amidst an email conversation regarding a proposed improvement to the Bitcoin protocol, the author of the proposal defends it against claims that it would make the protocol more stateful. They argue that each reply is only the result of the current request and does not introduce new session information. On the other hand, another individual suggests that there is still state involved in the proposal, as certain commands require keeping track of previous requests. However, the author counters this argument by stating that many of the described commands already have a natural nonce and do not require additional administration.The proposed change in question focuses on distinguishing between replies and spontaneous notifications from the other peer, with all state still being tracked locally on the client side. The author is confused as to why the proposal would be seen as making the protocol more stateful, as each reply is simply a result of the current request and does not introduce new session information. Additionally, the proposed change does not directly improve peers that do not answer requests, but rather enables easier implementation of this improvement when all peers are running the modified code.The proposal aims to add a new "requestid" field in messages as a part of improving blockchain downloading. This addition would provide context information to help distinguish between responses to "getblocks" requests and spontaneous "inv" notifications. However, some members of the email conversation express concerns about the change. They argue that stateless protocols are easier to implement and prove correct, and they worry about the potential costs and vulnerabilities associated with relying on external parties for state maintenance. Despite these concerns, the discussion emphasizes the importance of ensuring the reliability and security of the Bitcoin network.In the email exchange, Christian Bodt proposes a bitcoin protocol improvement that involves adding a request/reply ID in all messages. This is intended to facilitate robust blockchain downloading by providing better handling of response and request messages. However, Jeff Garzik disagrees with the proposal, stating that the problems mentioned can be addressed without adding "requestid" fields. He argues that stateless protocols are easier to implement and prove correct, and he cautions against relying on external parties for state maintenance due to the potential for exploitation.The context also mentions a patch for modifying the behavior of the Bitcoin protocol related to making a second "getblocks" request. This modification always results in one "inv" reply with [0-500] elements and removes the filtering on previously transmitted block invs. The patch can be found on the GitHub repository of the Bitcoin project.In another email exchange between Pieter Wuille and Gavin Andresen, the topic of adding request/reply ID to all messages in the Bitcoin protocol is discussed. While Andresen sees it as a reasonable improvement, Wuille points out that the Bitcoin P2P protocol is mostly stateless, which enhances its security. Wuille suggests the addition of a "denied" message instead, to indicate when a client is unwilling to answer and report transactions not accepted into the memory pool.Gavin Andresen posts on the bitcoin developers' mailing list about the proposed improvement suggested by Christian Bodt. The proposal involves adding a request/reply ID in all messages similar to the "checksum" field. Andresen finds the proposal reasonable and seeks others' opinions. However, Pieter Wuille notes that the Bitcoin P2P protocol is not fully request-reply based, making the proposed change less intuitive. Wuille suggests including an additional "denied" message to indicate an unwillingness to answer and report rejected transactions.Christian Bodt from France proposes a Bitcoin protocol improvement by adding a "request/reply id" field in all messages. This aims to facilitate robust blockchain downloading by providing context information. Christian has already implemented a prototype of this proposal and shares it for reference. The discussion surrounding this proposal arises from reading the PONG BIP and observing a similar nonce field, leading to uncertainty about the necessity of the nonce field with the presence of request/reply ids.
Updated on: 2023-08-01T03:26:12.873195+00:00