Published on: 2012-03-31T12:28:28+00:00
In a recent email thread, Michael Grønager has proposed pushing libcoin to bitcoin as a solution to various issues. He is willing to change the copyright/license if necessary but notes that a license change would be required for any merging to occur. Libcoin, unlike bitcoin, is designed without global thread mutexes and does not block the main thread due to rpc methods, except for a sendto. Additionally, a reorganize operation only briefly locks the main thread while the final commit is made. While Pieter Wuille likes the design and refactorings of libcoin, he expresses some concerns about its thread-safety. He suggests implementing reader and writer locks in each publicly accessible method of BlockChain to ensure proper synchronization. The libcoin rpc supports keep_alive and pipelining and runs in its own thread, but it can also run in the same thread as the node using async operation. Implementing IPv6 support in libcoin is relatively easy, as the CAddress/Endpoint class is already implemented as a subclass of boost::endpoint. The main obstacle to implementing IPv6 support is deciding on an IPv6 format on IRC. Lastly, Pieter suggests reversing the order of the last 12 bytes in the address database since they are opposite to boost.In regard to updates for bitcoin version 0.7, Luke-Jr provides a list of changes that are ready for merging. These include multithreaded JSON-RPC with keep-alive support, optimized ToHex function, FastGetWork, getalltransactions, and getblock_full. Luke-Jr also calls for better encapsulation of wallet and blockchain data structures to allow for safe multithreaded RPC. Pieter's IPv6 support is nearing completion, although there are still some issues to address, such as relaying and potential risks for DoS or other vulnerabilities. Enabling IPv6 support could open up possibilities for bitcoin to function as a Tor or I2P hidden service.Pieter Wuille raises the issue of nodes accidentally connecting to themselves in an email thread. With the switch to IPv6 and multiple local addresses, the chances of this happening increase. There are potential risks involved, including DoS vulnerabilities. However, Pieter later clarifies that he meant two nodes connecting twice to each other, for which there is already protection in place.Luke-Jr provides a compilation of changes ready for merging into bitcoin version 0.7. He suggests starting the release candidate (RC) process and mentions the need for rebasing the first merge. Some changes that have already been acknowledged for 0.7 include Hearn's "pong" message and Wladimir's Visual C++ 2010 fixes. The standardization of getmemorypool BIP is also acknowledged, but it might be better to wait until later in the merge window. Luke-Jr highlights the importance of merging multithreaded JSON-RPC with keep-alive support, as it has undergone extensive testing and is crucial for high-volume bitcoind usage. Other optimizations by Joel, such as the optimized ToHex function and FastGetWork, significantly improve the performance of JSON-RPC. Additionally, Pieter's getalltransactions and Luke-Jr's getblock_full provide the necessary functionalities to replace Jeff's old dumpblock call with bitcoind's new getblock. There are several other changes proposed, including refactoring the coin selection algorithm, implementing the standard reopen-log-files-on-SIGHUP, and adding a JSON-RPC call to customize fee requirements. Scott has submitted a pull request for Bitcoin-Qt to behave more like other close-to-systray applications, and Nils is working on a complete redesign of Bitcoin-Qt's user interface. Coderrr's Coin Control features are also nearing completion and should be merged soon. Lastly, there is hope that Pieter's IPv6 support will be ready for version 0.7, although only support for multiple local IPs has been submitted so far.
Updated on: 2023-08-01T03:24:59.640736+00:00