Published on: 2013-11-19T17:54:34+00:00
In a conversation about the Bitcoin protocol, Peter Todd expressed his belief that the reference implementation should be considered the real specification, while the information on the Wiki is more like a set of notes. He acknowledged that people who are familiar with the source code do not rely heavily on the Wiki. However, Todd emphasized the importance of openness and transparency in the protocol to instill trust in the system. He suggested that alternate implementations are likely to emerge and that accurately describing the rules should include a notice indicating that it is descriptive rather than normative. Todd also offered his assistance to anyone interested in working on documenting the protocol and its semantics.Another discussion focused on the need for a formalized specification for the Bitcoin protocol to reduce bugs and encourage alternate implementations. The challenge, however, lies in the reluctance to move away from the reference client due to concerns about working on a forked chain or having inaccurate data as a client. One proposed solution is to take small pieces, reach consensus, use universal test cases, and run tests on the testnet. It was suggested that qualified individuals could handle transactions/scripting, but others are welcome to join. While the reference implementation serves as the specification, the information on the Wiki is seen as a condensed version of the real specification. Some have questioned if the information on the Wiki is intentionally obscured to encourage people to check the source code. Despite this, it is important for the protocol to be transparent and documented to build trust in the system.Christian Decker discussed the historical background of the Bitcoin protocol specification, which started over three years ago with an attempt to document the network protocol by reverse engineering it from the Satoshi client. The goal was to enable engineers to create alternative clients and move away from a single client dominating the network. Although the protocol description has improved, Decker does not consider it a complete specification. He believes that having a specification allows for an application-independent review of the protocol to identify improvements and bugs. Decker expressed his desire to see the protocol specification become an official part of the Bitcoin GitHub repository alongside the Satoshi client.In a conversation about consistency in Bitcoin's documentation, Pieter Wuille emphasized the importance of accurately describing the rules of the system while making it clear that the documentation is descriptive rather than normative. He argued against making it difficult to find information about the system, as alternate implementations are likely inevitable. Wuille suggested that extensive documentation of the source code, similar to Knuth's literate programming, could be a middle ground. The discussion raised questions about whether alternative implementations are more likely to have incorrect protocol descriptions or misunderstandings of the reference implementation source code. Wuille offered his availability to answer any questions about the protocol and its semantics.Jeff Garzik highlighted the lack of associated documents for Bitcoin Improvement Proposals (BIPs) 40 and 41 in an email exchange. The group agreed that BIPs should not be used to force ideas onto others but to build consensus and document agreements. Gregory Maxwell and Drak discussed the allocation of numbers for draft proposals, with Maxwell explaining that the IETF distinguishes between individual proposals and accepted documents by working groups. Wladimir suggested creating a repository on Github to store BIP drafts, which received support from Drak. Peter Todd volunteered to create the repository, which would allow new BIPs to use either markdown or MediaWiki format.In a discussion about the Bitcoin protocol specification, Peter Todd emphasized that the reference implementation serves as the true specification for Bitcoin, while the information on the wiki pages is more like simplified notes. He clarified that the wiki pages are not deliberately obscure but are contributed by individuals who are not involved in the development of the reference implementation. Martin Sustrik questioned whether the notes were intentionally vague to force people to check the source code.Jeff Garzik suggested a distributed approach to writing Bitcoin Improvement Proposals (BIPs), where anyone can submit a pull request to improve a draft. Martin Sustrik expressed interest in participating but was concerned that the spec was deliberately vague to force compatibility with the reference implementation rather than with a document. Peter Todd explained that the reference implementation is the actual specification and advised those who don't understand this to assume that the protocol is fixed and doesn't evolve much.Gregory Maxwell and Martin Sustrik discussed the relevance of Security Considerations in RFCs for Bitcoin. Maxwell suggested that conformance with certain sections of the specification is necessary for security. Sustrik agreed and stated that all implementations must support the current version of the protocol, regardless of whether it has been documented and published. He also recommended using RFC 6919 keywords in the Bitcoin protocol RFC to convey different levels of importance and requirement.Martin Sustrik expressed frustration with the lack of a comprehensive protocol specification for Bitcoin and offered to help create one if necessary.
Updated on: 2023-08-01T06:01:52.857239+00:00