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, 13 changes were merged. Here are some I thought were interesting from this week.

• Broadcast own transactions only via short-lived Tor or I2P connections by vasild

  This is one GIANT change that has been open since February 2024. The goal of this PR is straightforward. When sending a transaction from your node, open a Tor or I2P connection that is immediately closed after sending.
  
  This change is a huge privacy boost for nodes and can interoperate with other nodes easily. For anyone wanting additional privacy, this would be good to enable, as currently, with the current method of transaction propagation, it is pretty easy for a node to know where a transaction originated from if they have multiple nodes connected to you. With this, your peer only knows you for the short duration they are connected with you over Tor or I2P.

• wallet: test: Relative wallet failed migration cleanup by davidgumberg

  This is a functional test for an issue that occurred last week, where if a migration of a legacy wallet with a relative pathname failed, then the relatively specified path where the wallet would be is deleted.
  
  This test shows that Bitcoin Core can handle the failed migration cleanup and failure scenarios correctly. This further ensures that this issue will not happen again because we have this test coverage now.

• mining: getCoinbase() returns struct instead of raw tx by Sjors
  This is a change to the mining IPC interface, which currently gets a raw Coinbase tx. This is not ideal as this requires the client to parse and manipulate Bitcoin Core’s dummy transaction. In this PR, Sjors renames getCoinbasetx() to getCoinbaseRawTx() to reflect more accurately what it does.
  
  Then he provides a replacement function getCoinbase() that includes a struct with everything a client needs to construct a coinbase, thus allowing the client to avoid having to parse and manipulate unnecessarily.
  
  The old functions are now deprecated.

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.

• Prepare string and net utils for future HTTP operations by pinheadmz

This is a component of removing libevent as a dependency of the project. It is the first six commits of #32061 and provides a string-parsing utility (LineReader) that is also consumed by #34158.

These are the functions that are added / updated for HTTP and Torcontrol:

• GetBindAddress(): Given a socket, provides the bound address as a CService. Currently used by p2p but moved from net to netbase so other modules can call it.

• ToIntegral(): Already used to parse numbers from strings, added new argument base = 10 so it can also be used to parse hexadecimal integers. HTTP chunked transfer-encoding uses hex-encoded integers to specify payload size: https://datatracker.ietf.org/doc/html/rfc7230.html#section-4.1

• AsciiCaseInsensitive comparators: Needed to store HTTP headers in an unordered_map. Headers are key-value pairs that are parsed with case-insensitive keys: https://httpwg.org/specs/rfc9110.html#rfc.section.5.1

• FormatRFC1123DateTime(): The required datetime format for HTTP headers (e.g. Fri, 31 May 2024 19:18:04 GMT)

• LineReader: Fields in HTTP requests are newline-terminated. This struct is given an input buffer and provides methods to read lines as strings.

---

IRC meeting notes

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

• Fuzzing WG Update (dergoegge)

  • dergoegge: Eugene has been working on incremental snapshot support for fuzzamoto (https://github.com/dergoegge/fuzzamoto/pull/103). This will hopefully, in the long run, enable the fuzzer to explore even deeper into the state space.

    I’ve open sourced the continuous fuzzing infra I’ve been running for the past years: https://github.com/dergoegge/fuzzor (there are no docs, but let marcofleon or me know if you want to run this as well)

    We’ve found a bunch of bugs using antithesis (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue%20author%3Adergoegge%20antithesis) (it’s only been a week, i’ll have more to say on this later/next coredev but lmk if there are questions).

• Kernel WG Update (sedited)

  • sedited: i’m on mobile, maybe stickies-v has something to add?

  • stickies-v: let’s keep it for next week

• Benchmarking WG Update (l0rinc, andrewtoth)

  • l0rinc: nothing from my side

• Silent Payments WG Update (Novo)

  • Novo: I’ve been doing some experiments to improve worst case scan

    With randomization of the outputs and removal, we can half scan time

    By removal, I mean removal of found outputs from the list

    Of course the scan time is still significant, 4 minutes on my machine

    I’m also working benchmarking LabelSet scanning with Blocks

  • There is a bit more conversation and questions on this

• Net Split WG Update (cfields)

  • cfields: No net split update this week. But I did manage to track down and work around the gcc bug slowing down the chacha20 impl that l0rinc mentioned here last week: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563#c13

  • cfields: For anyone wondering why I’m spending _so_ much time on chacha20, it’s because I’m hoping to prove that writing generic vectorized code like this is a reasonable way forward for us for our low-level bottlenecks. If so, we could be more liberal with adding simd code as it’s easier to review than bare asm.

• Constant build failures on forked repos since introduction of `Valgrind fuzz` C job (l0rinc)

  • l0rinc: The Valgrind fuzz job was introduced in e4b04630bcf59ea03c1373777a0167af699f92a4. Since then, ci/test/00_setup_env_native_fuzz_with_valgrind.sh seems to regularly time out on forked repositories (which fall back to GitHub-hosted runners), hitting the 240 minute job timeout, see: l0rinc/bitcoin/actions/runs/21003573850/job/60381011678

  • l0rinc: I first tried bumping the timeout to the GitHub Actions maximum, since the run took 4h 36m 50s.

  • l0rinc: maflcko suggested that we rather remove it from the CI matrix since it didn’t reveal anything (similarly to how the valgrind no-fuzz task is handled) - which was rejected by others, see: #34304

  • There was also some more conversation around this

Be sure to read the Meeting in Minutes for the full conversation

---

Releases

• Bitcoin Core v30.2 Released

---

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

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment