Lower protocol_version_min for V25.1 compatibility during upgrade#54
Open
yusufgurdogan wants to merge 9 commits intoBananoCoin:v28from
Open
Conversation
Increased bootstrap performance settings to significantly speed up blockchain synchronization: - 4x more bootstrap connections (4→16 outbound, 64→128 inbound) - 8x higher rate limits for block requests - 10x bandwidth increase (5MB/s → 50MB/s) - 4x more concurrent threads for bootstrap operations - Enhanced frontier scan parallelism and reduced cooldowns This should increase sync speed from ~500 blocks/min to 2500-5000+ blocks/min.
…015jejAtRDUU58KDBExda97E Optimize bootstrap configuration for faster sync
…o-blocks-015jejAtRDUU58KDBExda97E Revert "Optimize bootstrap configuration for faster sync"
This change temporarily lowers protocol_version_min from 0x12 (18) to 0x11 (17) to allow V28.2 nodes to communicate with existing V25.1 nodes during the network upgrade transition period. Without this change, V28.2 nodes reject all V25.1 connections with "outdated_version" errors, preventing the network from functioning during the upgrade. This should be reverted once >90% of the network has upgraded to V28.2. Changes: - protocol_version_min: 0x12 -> 0x11 - bootstrap_protocol_version_min: 0x12 -> 0x11
- Add missing <algorithm> include for std::copy_n in numbers.hpp - Suppress deprecated declarations globally for RocksDB compatibility
The root cause of "dead channel" evictions was that V28.2 queries random recent blocks that V25.1 nodes don't have yet. When V25.1 nodes don't respond (because they lack the queried blocks), V28.2 marks the channel as dead and evicts the representative. This fix makes V28.2 always query the genesis block, which ALL nodes have, ensuring V25.1 nodes can respond and maintain connections. This is a temporary workaround for the V25.1 -> V28.2 direct upgrade path. After the network fully upgrades to V28.2, the original random block query logic can be restored.
V25.1 nodes use protocol version 0x10 (16) or older. The previous fix of 0x11 (17) was still too high, causing immediate channel death when V25.1 nodes send messages. Lowering to 0x0F (15) provides sufficient margin to accept V24, V25, and V25.1 connections during the upgrade transition period.
V25.1 nodes have behavioral differences from V28.2 that cause channels to die quickly (different message handling, connection management, or response formats). Instead of permanently evicting these reps, keep them in the rep list. The crawler will reconnect on the next query cycle. This prevents constant rep churn during the upgrade period. The total_weight() function already filters dead channels, so weight calculations remain correct. After the network fully upgrades to V28.2, restore the original aggressive eviction logic.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.