IRC meeting summary for 2016-11-03

• Link to this week logs
• Meeting minutes by meetbot

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.

Main topics

• Block header/fetch logic
• BIP152 changes

Block header/fetch logic

background

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.

meeting comments

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.

meeting conclusion

• start by adding a timeout for headers fetch
• discuss further after the meeting

BIP152 changes

background

BIP152 Compact Block Relay has been in Core since 0.13.0. in order to reduce the bandwidth used and latencies during block relay.

meeting comments

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.

meeting conclusion

• Wait until no changes are made for a while before making the BIP ‘final’.

Comic relief

gmaxwell          In any case, I still think that the BIP discussion belongs elsewhere. :)
morcos            well you come up with something else to talk about for 11 more minutes then!

gmaxwell          wumpus: sipa: thanks for merging lots of stuff!
BlueMatt          <3
sdaftuar          +1
BlueMatt          making 0.14 great again!

wumpus            so I guess in practice it fixes testnet issues only on 0.13.2, so the question would be is that worth it to potential regressions?
gmaxwell          <famous last words>I can't see it causing a regression.</famous last words>

Participants

Disclaimer

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.