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.

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.

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.