Published on: 2011-09-05T14:32:36+00:00
The writer of the email conversation in 2011, Mike Hearn, discusses the possibility of writing a patch for Bitcoin with his correspondent. However, the correspondent suggests that it would be more useful to focus on addressing root issues within the network. One of these root issues is nodes being able to determine their own suitability before becoming advertised listeners. This is because determining suitability is not always straightforward, as a node may have connectivity with a peer but experience slow speeds due to link saturation.To address this issue, the speaker suggests two solutions. The first solution is to make it easy to determine latency and use that data to make better connection decisions. They propose adding a "pong" response to the existing "ping" message. This would allow useful statistics about the node to be collected and let nodes be ordered by responsiveness. Currently, ordering nodes by responsiveness can only be done indirectly through messages that yield a known response. The addition of the pong response would be easy and backwards compatible.The second solution suggested by the speaker is to build latency histograms of nodes to assess network performance. This data can then be used to inform simulations of what would happen if the measurements were used by node software. By conducting simulations, experimentation can be done with less critical software like Android clients, allowing for validation of proposed changes.The writer also considers writing a patch for an issue related to nodes under heavy load exhibiting extremely high latency, which makes downloading the blockchain from such nodes useless. To fix this issue, the writer suggests making nodes not accept connections or advertise until they are certain they have the best chain. However, a more general fix is proposed: adding a pong response to the ping message. This would not only solve the issue of nodes under heavy load, but also provide useful stats about the node and allow nodes to be ordered by responsiveness.It is noted that care must be taken to avoid sloshing load around too much when making nodes prefer responsive servers. The writer seeks input on the proposed solution and acknowledges that testing on the real network is important but difficult due to its slow upgrade process. The current testnet is also deemed too small and unlike the real network to provide useful results.
Updated on: 2023-08-01T02:23:33.419546+00:00