Published on: 2011-07-13T21:41:29+00:00
In a discussion thread from July 2011, the value of the TCoinsElement MAX_MONEY in bitcoin's source code was questioned. The value of 21,000,000 was argued to be arbitrary, but Andy Parkins defended it as the outcome of a calculation. The MAX_MONEY constant is likely a limit on the amount of coins that can be used in a program or application. The discussion also touched on various other constants related to Bitcoin, including coinbase maturity, block size, and transaction fees.The discussion also mentioned BitCoinJ's NetworkParameters abstraction, which groups constants together for easier testing and chain creation. It was suggested that a similar abstraction could be implemented in the Satoshi client. There was also talk about creating a new library called 'libbtc' to handle specific functionalities, such as IRC or P2P connection handling.The email thread further discussed the idea of a complete rewrite of the Bitcoin codebase. While some believed it was necessary, others argued for incremental improvements instead. Concerns were raised about using Berkeley db 4 and Boost as dependencies, but it was noted that Boost is now considered standard C++. The importance of clean, well-documented code was emphasized, as well as the need for consistent blockchain validation logic.In another conversation, the one class-per .h/.cpp rule was discussed, with different opinions on whether it should be strictly followed or not. The benefits of putting logically similar code together versus splitting it into many small files were debated. It was suggested that finding a balance between the two approaches would be best for the Bitcoin codebase.There were also discussions on managing connections and peers, interpreting messages, and improving the overall design of the Bitcoin daemon. Some participants advocated for a complete rewrite of the codebase, while others believed in making incremental improvements. Gavin Andresen proposed focusing on network-protocol-level testing and expressed concerns about using multiple threads and mutexes.Overall, the discussions revolved around improving the Bitcoin codebase through clean and well-documented code, refactoring, testing, and finding a balance between different coding approaches. The importance of creating a reference project for other clients and making Bitcoin more accessible to new developers was emphasized.In an email sent on July 10, 2011, Michael Offel expressed concerns regarding the long build times for Bitcoin. Comparing it to other projects with millions of lines of code, he noted that Bitcoin took significantly longer to build. Offel attributed this issue to the use of boost, a lack of module isolation, and implementations in header files. He offered to address the latter concern on IRC by removing implementations from the headers. However, his proposal was rejected due to the large size of the pull request, contributing to lengthy build times and complicating the addition of new code due to build dependencies.Douglas Huff responded to Offel's email, acknowledging the validity of his concerns and suggesting further discussion and resolution. The writer of the email expressed apprehension about the code quality in Bitcoin and proposed a plan for cleanup. They highlighted various issues such as the absence of code documentation, inadequate utilization of threads, hardcoded values, and the aforementioned long build times.Moreover, the writer emphasized the need for module isolation to enhance code comprehensibility. They recommended a complete rewrite of the code, drawing inspiration from the existing code but with improved documentation and cleaner implementation. As the official Bitcoin client serves as a reference project for other clients, it is crucial for it to be exceptionally clean and well-documented.Importantly, the writer clarified that they were not assigning blame for the current state of the code. Instead, they expressed their willingness to dedicate time and effort to the project, emphasizing their commitment to improving its quality.
Updated on: 2023-08-01T02:07:06.515159+00:00