Published on: 2014-05-26T15:08:46+00:00
The discussion revolves around whether to run experimental p2p code inside production bitcoinds or to run an experimental gateway in another process on a node. It is suggested that running the experimental gateway during the development phase would be better. However, if the code proves valuable, it should eventually be integrated or rewritten into Core to avoid increasing the setup cost of running a node and ending up with a two-tier network. The tradeoffs involved in this decision are complex and subtle. If the code will eventually be merged into Core, it might as well be implemented directly into it, perhaps behind a switch that can disable those code paths if something goes wrong.Bitcoin developer Mike Hearn discussed creating an alternative to the current P2P protocol in an email exchange with others. While some argued that it could improve feature velocity, Hearn pointed out that implementing features twice in two protocols would slow things down. However, he did concede that certain use cases might require an alternative protocol. An advantage of an alternative protocol is that it can proceed asynchronously with implementation development, allowing for faster revving of versions. Additionally, if there are bugs, it wouldn't break the nodes using it, making it less risky than experimental p2p code inside production bitcoinds themselves.The idea of having multiple protocols for Bitcoin transport is suggested for better robustness and feature velocity. However, implementing features twice in two different protocols could slow things down. The current p2p protocol is considered efficient, and fixing the 100msec sleep and measuring latency and queuing inside the code are seen as the lowest hanging fruit for improvements.In an email conversation between Gregory Maxwell and Alan Reiner, they discussed a modification in the way Bitcoin Core prioritizes blocks. Currently, it uses the first full block verified as the highest priority, but Reiner suggests considering the first valid header received as the highest priority. Maxwell points out that this would open up an attack where someone could delay announcing the block content and continue to mine on the block without others being able to do so. Maxwell suggests putting an expiration on the logic by ignoring the header-received time if the full new block hasn't been received within 5-10 seconds. They also mention Ashley, who is apparently working on solving this issue.Bitcoin Core developer Alan Reiner proposed modifying the way Bitcoin Core prioritizes blocks in an email from May 2014. Currently, it uses the first full block verified instead of considering the first valid header received as the highest priority. Reiner suggests this change because the current system opens up an attack where one can delay announcing the content of a block while continuing to mine on it. Reiner also addresses concerns about the 1-3 second gap that could occur with the new system and advises miners to focus on making sure the transactions they are mining are well-propagated already. Additionally, he suggests that with an alternative transport protocol, similar latency could be achieved without increasing the motivations for miners to misbehave.In a discussion among Bitcoin Core developers on May 24, 2014, concerns were raised about potential denial of service (DoS) attacks on the Bitcoin network. One developer notes that an attacker with sufficient hash power could use cut-through forwarding to carry out such an attack, while another points out the possibility of a teergrube attack in which the attacker prevents blocks from being transmitted to the network. The conversation also focuses on issues related to block propagation and suggests improvements to the peer-to-peer protocol. One proposed solution is to allow for multiplexing of messages using something like HTTP chunked encoding to prevent slow messages from causing delays. Another suggestion is to modify the way Bitcoin Core prioritizes blocks by giving priority to the first valid header received rather than the first full block verified. This would allow nodes to mine on whatever full and verified block they have with the earliest header-received time, switching to mining on a new block only once it has done full verification of the block.Bitcoin's ability to establish the primacy of blocks by time through incentives arising from block propagation times has been underestimated. Partitions on the network evolve as a block is propagated, with blocks reaching over 50% of the network in five seconds. This means that 50% of the hashing power are already building a block that builds on top of the block that is already circulating, resulting in a fast decline in the probability of a collision on the network. However, miners who are less well connected to the network may find block propagation times a bigger issue, as they spend more time mining redundant problems and may find blocks to compete with blocks that are already spreading throughout the network.In a discussion among Bitcoin developers on May 25, 2014, concerns were raised regarding possible attacks on the network.
Updated on: 2023-08-01T09:24:15.616429+00:00