l0rinc

> I'll compare the reindex-chainstate performance next, before & after, let's see if there's a regression (we do expect a 4% slowdown for max cache, like in IBD). IBD seems...

> I'll retry it with 100 minutes to see if it would fix the situation. With 100 mins it's **7%** slower instead of **11%** - still quite bad, but we...

ACK 6ecb9fc65f9a5654663304757880e50d73cf4a84

reACK 342359f9538874a87b86b67dd98f81cb78237a1e typo fix + `commit_offset` was change since last push to depend on `commitment_period `

Given that the current PR already demonstrates the production code is still correct, I tend to agree that we don't have to rush. Would have been cleaner, but it's not...

reACK 33d550d3044f9075cc866093c453158288f12dec Would be great if @sipa or @sdaftuar could also take a look.

reACK 794a17186d3019713d29213bedd866baa1c81378 - the only change since last ACK was the span nits being applied

reACK cc5dda1de333cf7aa10e2237ee2c9221f705dbd9 The only difference after the rebase is a removal of a `constexpr` in one of the `base_uint` constructors. > changed PR-title (category) from "headerssync:" to "p2p nit: the...

@maflcko, the Fuzz tests seem to be timing out now, is the new setup too heavy, should I maybe add them to different suites?

> it seems odd that the fuzz tests would time out here Split the big fuzz target into separate base58_encode_decode / base58check_encode_decode / base32_encode_decode / base64_encode_decode / psbt_base64_decode - it's...