Published on: 2012-06-12T10:50:40+00:00
In an email thread dated June 11, 2012, the complexity of BIP 22 is discussed by various individuals. They express their desire to simplify it and gather feedback on the key features that will likely be used by pool customers. The discussion focuses on whether the proposed 20 optional features are necessary, rather than the usefulness of getmemorypool. One individual specifically mentions Electrum servers as users of these features.The Sourceforge mailing list system experienced issues over the weekend, causing multiple copies of Pieter's messages to appear in people's inboxes. These extra copies have been deleted from the mailing list archives. As a result of the mailing list problems, the discussion shifted to the pull request on Github regarding BIP 22. Gavin Andresen and Pieter both believe that BIP 22 is overly complicated and wish to simplify it. Gavin is particularly interested in knowing which features will be commonly used by pool customers versus those that will only be used by a small percentage of them. He encourages further discussion on the topic.Pieter, a member of the Bitcoin community, expresses concerns about the complexity of the BIP 22 standard for negotiating block generation. He believes that while having a stable and flexible API is important, too few people understand the details well enough to judge their necessity. Pieter suggests that the standard should not be more complex than necessary and its purpose and intended use cases should be clear.Pieter points out several issues with the current BIP 22 standard. He questions why full transactions (serialized in hex) are sent in templates and submissions, suggesting that transferring txids may be sufficient. He also believes there are too many optional features in the standard, such as variations in coinbase outputs and noncerange limiting, making it unnecessarily complex for clients. Additionally, Pieter dislikes several ways of specifying the same behavior and recommends picking one flexible way and discarding the others.In summary, Pieter suggests simplifying the standard to include only `getblocktemplate` and `submitblocktemplate`. The former creates a new block template and returns it, while the latter submits an object containing a hex serialized block header, hex serialized coinbase transaction, and a list of txids. Proof of work is checked last, so that error is only returned if there is no other problem with the suggested block.Pieter Wuille, a Bitcoin developer, has also posted in the bitcoin-development mailing list about his concerns with the BIP22 protocol. He emphasizes the importance of having a stable and flexible API for negotiating block generation standardized. However, he believes that too few people understand the details of BIP22 and its intended use cases. Wuille suggests simplifying the standard by reducing the number of optional features and ways of specifying the same behavior. He proposes creating a new block template with specific fields and submitting an object containing necessary information. Wuille asks for feedback on any important use cases that may have been missed.
Updated on: 2023-08-01T03:34:28.220192+00:00