This week in Bitcoin Core

Bitcoin Core contributor kevkevin covers some of the latest updates...

Hello 👋 folks, I’m kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo. Here’s what I found notable.

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 36 changes were merged. Here are some I thought were interesting from this week.

• p2p: Correct unrealistic headerssync unit test behavior by hodlinator
  Previously mentioned in the article below

• As mentioned earlier, this avoids testing the unrealistic behavior of the header sync before reaching the REDOWNLOAD_BUFFER_SIZE by having tests that can define their own values through the new HeadersSyncParams.

• log: print every script verification state change by l0rinc
  There are cases where script checks are enabled unexpectedly. Without an explicit log line, the users must guess what the state is based on the absence of a message, which may be difficult to do.
  
  There is currently a log that starts with “Assuming ancestors of block…”, but it does not really indicate if script checks are enabled, making debugging confusing. In this change, the initial script verification state logs explicitly why the checks are enabled to avoid confusion.

• ci, iwyu: Treat warnings as errors for specific directories by hebasto

  IWYU stands for include what you use. The goal of this PR is to treat warnings as errors for specific directories. To help understand the goal of this PR, it is important to understand what iwyu does. Here is a blurb from their website.

“Include what you use” means this: for every symbol (type, function variable, or macro) that you use in foo.cc, either foo.cc or foo.h should #include a .h file that exports the declaration of that symbol. The include-what-you-use tool is a program that can be built with the clang libraries in order to analyze #includes of source files to find include-what-you-use violations, and suggest fixes for them.

The main goal of include-what-you-use is to remove superfluous #includes. It does this both by figuring out what #includes are not actually needed for this file (for both .cc and .h files), and replacing #includes with forward-declares when possible.

---

Open PR’s

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us by SatsAndSports
  Keep in mind, this is a controversial change.

The DNS seed dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us. is not returning a representative sample of bitcoin nodes. It currently returns nothing later than 28.1.0, breaching the policy.

This PR removes that seed from the list of DNS seeds

---

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

• Erlay WG Update (sr_gi, gleb)

  • no update

• Fuzzing WG Update (dergoegge)

  • dergoegge: no update

• Kernel WG Update (TheCharlatan)

  • TheCharlatan: Been getting review on #30595 and asking for even more :)

• Benchmarking WG Update (l0rinc)

  • l0rinc: I forgot about the meeting, will report at the end :)

  • later in the meeting..

  • l0rinc: We’ve been discussing the parallel block input fetcher with Andrew Toth, we had a lot of ideas on how to make it even better and we’ve achieved 25% reindex-chainstate speedup there on an Rpi5 with default 450 MB memory.

  • l0rinc: I have investigated if sorted UTXO fetching would also be faster (like how sorted writing is also done) - and it revealed a 4-10% speedup even on a single thread. So I will try to see how this fits into the parallel fetching in general.

  • l0rinc: I have also just checked two ideas that we’ve discussed with sipa

  • l0rinc: hiding the bip30 checks behind assumevalid, which would enable us removing the bloom filters from LevelDB since we won’t need to check for missing entries anymore. This seems to shrink the on-disk UTXO size by roughly 1% (122MB smaller, see the draft here https://github.com/l0rinc/bitcoin/pull/49) while slightly speeding up IBD as well. I’d be interested in what concerns people have about this idea.

  • l0rinc: The other idea we’ve discussed was to use a simpler SipHash for the volatile usages (e.g. hashmap keys) and we’ve both contacted the author who agreed that we don’t actually need a heavyweight SipHash24 for these cases, but a Siphash13 or even a dedicated SipHasher for our use case would likely suffice. I will code these up later, but I the prototype shows measurable IBD speedup around 4%.

• Silent Payments WG Update (RubenSomsen)

  • achow101: we may need to change who is reporting for silent payments

  • dzxzg: I nominate josibake :D

• Cluster Mempool WG Update (sdaftuar, sipa)

  • instagibbs: cluster mempool is still #33629 fwiw, one thing to review

• Stratum v2 WG Update (sjors)

  • Sjors[m]1: No news atm

• QML GUI WG Update (johnny9dev)

  • johnny9dev: For gui-qml I’m working on getting depends/guix building for the project. I have a solution using patches and the submodule’s depends makefile that is working for me locally. Will PR that soon. For guix, I don’t have a solution yet.

• Script Validation WG Update (fjahr)

  • fjahr: I’ve implemented a more convenient way to check performance across multiple thread worker configs in #33740, which will be helpful for this work. Looking for feedback if this is generally useful enough to be considered for merging. Nothing to report aside from that.

• Net Split WG Update (cfields)

  • eugenesiegel: nothing to report yet

• rotating irc meeting chair (achow101)

  • achow101: as was mentioned last week, we should have more than one person doing irc meetings. since we have previously fallen into the trap of the tragedy of the commons when there wasn’t anyone who was specifically suposed to do it, I think we should setup a rotation of 3 or 4 people.

  • fjahr: Still happy to take part in this, I’ve stepped in once or twice in the past. But the time of day recently hasn’t always been ideal for me so I will have to skip the meeting from time to time. But I should know that well in advance and so I can take some of the meetings with prior coordination.

  • achow101: I’m still willing to run them

  • dergoegge: i fell like a bot (with llm in hand) could do it?

  • stickies-v: i’m happy to run a few too

  • glozow: dergoegge are you volunteering to run them using a bot?

  • achow101: dergoegge: for most meetings sure, but there’s edge cases where the chair needs to actually cut off a discussion when it gets off topic or starts running over time

  • dergoegge: i can prototype a bot and we can test it out?

  • achow101: fjahr: stickies-v: great, I’ll reach out privately

  • achow101: dergoegge: go ahead

For the full log, check the meeting in minutes

---

Releases

• No major releases

---

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!