Published on: 2014-06-30T10:16:01+00:00
The task at hand is to create a graphical interface for bitcoind on Linux servers. This interface should display a summary of necessary data for node administrators in the Terminal using ASCII characters. A tool called bitcoind-ncurses has already been developed for this purpose and is available on Github, but it is still in its early stages and may require assistance to become a fully-functional node admin tool.In a May 2014 email thread between Jeff Garzik and Raúl Martínez, the possibility of adding bitcoind and Bitcoin Core to Linux repositories is discussed. However, certain conditions must be met before this can happen. These conditions include allowing bitcoin developers to dictate which dependent libraries are shipped with or built statically into the bitcoin binaries/libs, enabling fresh updates to older stable distributions, and having active maintainers who closely follow bitcoin development and release status. Matt C's PPA is mentioned as an example of meeting these conditions in Ubuntu. It is noted that while conditions (1) and (3) are feasible, condition (2) poses difficulties due to Debian and Ubuntu policies. Alternative mechanisms such as backports, volatile, and updates repositories could meet condition (2), but user intervention is required, and they are not enabled by default. Debian unstable allows for condition (2), but the package is blocked from transitioning to a stable release. Matt C's PPA remains the best option for meeting all three conditions in Ubuntu, and the Debian unstable package is deemed the most suitable for Debian, although both require users to add a line to their apt sources list.The Bitcoin network is exploring ways to limit rates and improve block download reliability. One suggestion is to introduce a service bit indicating that a node has chain data and is willing to Bloom filter it for others, without serving full block data. This would allow home users with low tolerance for block chain uploads to contribute useful services to the network. The idea of an "archival node" service bit is also proposed. It is suggested that the capabilities of "I have CPU and can filter" and "I have bandwidth and can serve" should be separated more explicitly.In an email exchange between Bjørn Øivind Bjørnsen and Wladimir, the implementation of network rate limiting in the bitcoin codebase is discussed. While Bjørnsen, who is unfamiliar with the codebase, suggests adding network rate limiting as a feature, Wladimir informs him that an old patch already exists for it but will only be merged when headers-first and parallel block download are in place. Wladimir explains that it is safe to limit rates once the node can download blocks from multiple peers simultaneously. He mentions the script in contrib/qos as a trick to limit rates but emphasizes that it needs to be widely available first.Adding a node with slow upstream/downstream speed may slow down the network's bootstrap process, but it does not harm the network itself. Existing issues can already cause the download process to take several days, and using the torrent is a faster alternative. However, a slow node may impede parallel downloading for remote peers.In a discussion thread initiated by Mike Hearn, the issue of network rate limiting in Bitcoin Core is raised. While acknowledging the importance of this feature, its implementation is recognized as a challenging task. Additionally, it is noted that throttling one's connection would cause remote nodes to give up and rely more on unthrottled peers. Bjørn Øivind asks if adding a node with slow upstream/downstream speed could harm the network and shares his own experience of using QoS to throttle his node. The article delves into the implementation of network rate limiting in Bitcoin Core. One challenge highlighted is that Bitcoin Core does not detect if a remote peer is working slowly and switch to a faster one. Throttling one's connection would lead remote nodes to give up and rely more on unthrottled peers. The suggested approach is to implement chain pruning, allowing the node to shovel bytes as fast as possible but limiting it based on the number of bytes available. Remote nodes pulling down the block chain can then switch between nodes to avoid overburdening a single node. Extending the p2p protocol is also proposed, with addr broadcasts and version messages indicating how much of the chain a peer is willing to serve. This would enable smarter peer selection during downloading. However, progress on these ideas awaits the completion of merging headers-first downloading. The article encourages experimentation with these approaches.A discussion among developers in 2014 focuses on the small number of Bitcoin nodes and potential vulnerabilities resulting from this. Financial incentives are proposed as a means to encourage more people to run nodes. A tool similar to Tor's 'arm' is suggested to provide users with information such as bandwidth usage, CPU usage, connected peers, and active configurations.
Updated on: 2023-08-01T09:19:54.827817+00:00