Pieter Wuille

@Sjors They may have just disconnected for whatever reason.

> Two reasons, I think -- one is that we use more memory that way, the other is that the bookkeeping seemed more complicated to think about than if we...

@instagibbs Yeah, there was some chatter about that, but it's genuinely hard to do: there isn't any global state that is even aware of the progress made until the second...

@instagibbs Yeah, there was some chatter about that, but it's genuinely hard to do: there isn't any global state that is even aware of the progress made until the second...

I've pushed to https://github.com/sipa/bitcoin/commits/202208_headerssync_log a series of commits to: * There is a lock ordering bug in the current branch, which can lead to a deadlock when opening the peer...

So a few open questions regarding the logging/progress: * Is it necessary to address logging/progress before 24.0? It's a somewhat bad UX if we don't, as there is no feedback...

> It depends on how many "a few". I guess an additional week will be enough for translators to update their translations with a couple of new strings. Two, both...

@ajtowns I believe you're seeing the effects of the mixing-in-`m_best_header`-based-skipping, but may be misunderstanding what is happening. First of all, `ValidatedAndStoreRedownloadedHeader` indeed doesn't deal with the peer deciding to continue...

> Restarting headers sync pushes you back into initial download, so the behaviour on testnet for a peer that's finished initial sync but skips some blocks during redownload looks like:...

``` 2022-08-15T21:18:57Z [headerssync] Initial headers sync aborted with peer=1: non-continuous headers at height=176001 (redownload phase) 2022-08-15T21:18:57Z [headerssync] Initial headers sync started with peer=1: height=666040, max_commitments=2124319, min_work=00000000000000000000000000000000000000000000002830dab7f76dbb7d63 ``` So, this is...