Published on: 2013-10-31T12:01:37+00:00
In an email thread from October 2013, Gregory Maxwell raised concerns about a race condition in which a node using priority queued rate limiting for relaying could accept a transaction but have it fall out of its memory pool before sending it to other peers. However, the author of the email believes this issue is trivial and can be easily resolved. They suggest that there is no requirement for a transaction to be placed into a buffer before relaying, and the small gap between relaying and placing the transaction into the buffer should not cause any issues. It is also noted that Gavin's smartfees branch adds mempool persistence to disk, ensuring that restarting nodes won't clear the mempool in the future. Additionally, the author points out that even if all nodes are honest and well-behaved, it cannot be guaranteed that they will forward transactions, making measuring propagation a necessary part of Bitcoin wallets.In an email from Mike Hearn on October 27th, 2013, he expressed excitement for a new development that would resolve issues with the current Bitcoinj library. The library had been receiving bug reports about transactions not propagating properly, which caused problems as the library selected only one peer to send the transaction to and waited for it to propagate across the network. If this peer refused the transaction, it would not propagate and cause issues. However, Hearn noted that there needed to be documentation explaining that a failure to reject a transaction did not guarantee its forwarding. He explained that if a node was using priority queued rate limiting for relaying, it could accept a transaction but have it fall out of its memory pool before sending it to other peers due to higher priority transactions arriving or getting restarted. Thus, it was not certain that a transaction would be forwarded without issue.In an email exchange from October 30, 2013, Mark Friedenbach discussed fork alerts with an unknown recipient. He clarified that his previous comment was not related to rejecting blocks but rather to the fork alerts that Matt had implemented. These alerts would notify users if an upgrade had been missed. The context provides insight into the technical workings of soft forks in Bitcoin. The author clarifies that a soft fork is an upgrade designed to appear valid to old nodes, relying on miner majority to return everyone "back on track". If new block versions change the serialization format or script language such that old clients reject the block, a hard fork occurs and the alerting code triggers. This discussion sheds light on the technical aspects of Bitcoin and how soft forks operate.In an email conversation between Mike Hearn and Gavin Andresen on October 29, 2013, they discussed the use of soft forks in Bitcoin. Hearn expressed concerns about the mechanism being flawed and undermining the security model of Bitcoin. However, Andresen pointed out that recent versions of the reference implementation would alert users if they were being soft-forked. A warning would be issued if more than half of the last 100 blocks declared a version number that was meaningless to them. The block.version, part of the block header, could also be used by SPV clients to issue warnings. Additionally, there were warnings for those who were forked and for those on a high-work alternative fork.In an email exchange between Peter Todd and Mike Hearn on October 29, 2013, the topic of using nVersion as a soft-forking mechanism was discussed. Hearn suggested having a separate code for blocks claiming to be v2 or v3 to prevent people from using nVersion for nonsense. However, Todd argued that rejecting blocks with unexpected nVersions would result in a hard fork. He also expressed his belief that the whole soft-fork mechanism was wrong and undermined Bitcoin's security model. He emphasized the idea that if rules changed, nodes were meant to end up on a chain fork and trigger an alert.In an email conversation on October 29th, 2013, Mike Hearn raised concerns about losing the nVersion field to people using it for nonsense if a separate code was created for "block is from the future" regarding block 0x11. However, doing so would prevent nVersion from being used as a soft-forking mechanism. Peter Todd responded, agreeing with Hearn's point and signed off with his email signature.Gavin Andresen proposed adding new reject codes for the Bitcoin protocol in a discussion on the bitcoin-development mailing list in 2013. He suggested organizing the codes into categories, such as syntax errors, semantic errors, and server policy rules. There were also debates about having separate codes for different versions of blocks and transactions. It was agreed that using HTTP codes directly would not be suitable, and varints for reject codes were deemed unnecessary as it was unlikely that more than sixteen codes would ever be needed.Warren Togami Jr. suggested using rejection codes to notify users that they had been rate-limited in an email exchange on October 28, 2013.
Updated on: 2023-08-01T06:19:41.977868+00:00