IRC meeting summary for 2016-11-03
Notes / short topics
- The final alert has gone out successfully.
- Wumpus wonders if PR #9053 (IBD using chainwork instead of height and not using header timestamps) should be backported to 0.13.2. It is harmless to backport and it does fixes the testnet issue where the non-segwit chain unintentionally triggers the testnet node into a state where they stop mining. What exactly to backport can always be decided later on.
- Block header/fetch logic
- BIP152 changes
Block header/fetch logic
During the initial block download (IBD) a ‘getheaders’ message is send which requests a ‘headers’ message that provides block headers from a particular point in the blockchain. This way many block headers can be downloaded at once.
Sipa explains a couple of related points:
- There is no time-out for headers requests
- We don’t respond to headers requests while in IBD, which can cause stalls if nodes mistakenly believe they are in IBD
- The block fetch logic only disconnects peers who slow down the process, we might have a peer who has no blocks we can fetch at all, and we never try and never disconnect them
He proposes to disconnect outgoing connections you’re not downloading from while in IBD but remove the non-response to ‘getheaders’ in IBD.
Gmaxwell proposes something stronger, namely when you have the maximum outbound connection, disconnect the peer that is the slowest to give you blocks during IBD every minute.
- start by adding a timeout for headers fetch
- discuss further after the meeting
BIP152 Compact Block Relay has been in Core since 0.13.0. in order to reduce the bandwidth used and latencies during block relay.
There has been some small bugfixes and improvements made that required the BIP text to be changed, for example sdaftuar’s Fix handling of invalid compact blocks. Luke-jr wonders when and if BIP-changes should be halted as now the BIP seems like a moving target for other implementations.
It might be unrealistic to think we’re not going to want to make small tweaks to complicated BIP’s after releasing an implementation, it is much clearer in the future to have the original BIP reflecting the final design.
Gmaxwell thinks this is more a topic for the mailinglist, not the meeting.
- Wait until no changes are made for a while before making the BIP ‘final’.
|wumpus||Wladimir van der Laan|
This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.