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, 26 changes were merged. Here are some I thought were interesting from this week.
http: replace WorkQueue and single threads handling for ThreadPool by furszy
In this pull request furszy explains that there was a recent discovery that the general thread pool class created in #26966 integrates into the HTTP server cleanly.
This is good because it simplifies the initialization, shutdown, and request execution logic. Also, on top of that, the existing code was never unit tested or fuzzed properly before; replacing it with code that functions better and is more thoroughly tested is a major win.
This also separates the responsibilities and gives the Bitcoin Core maintainers the ability to experiment with future performance improvements.refactor: separate log generation from log handling by ryanofsky
If you’ve read this weekly newsletter before, then you know what a refactor change means. This change was mostly move-only. The major noticeable difference because of the change was that instead of using/including the full logging.h implementation, we can instead use the util/log.h, which is simpler.
The original motivation of this change was to reduce the size and complexity of a Kernel change (kernel-structured logging).txgraph: deterministic optimal transaction order by sipa
In this PR sipa explains that it is the fundamental responsibility of TxGraph to decide on the ordering of the transactions in the mempool. TxGraph relies on cluster_linearize.h in order to optimize the ordering, but oftentimes, there can be multiple solutions that are essentially equivalent in quality.
This means that we have to pick one. Sipa explains that the solution will be determined by one of the following: internal identifiers, random selection, txid, or size.
Currently, it is picked at random. In this PR, sipa describes exactly how transactions will be picked now. The main thing I noticed is that now the transactions are picked deterministically.
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.
Modernise our lint tooling by:
- Replacing pyenv + pip with uv for better Python environment and dependency management
- Replacing mypy with https://github.com/astral-sh/ty
- Replacing the 01_install.sh runtime install script with COPY --from multi-stage Docker image imports for uv, ruff, shellcheck, mlc, and ty
- Moving ruff lint rules from hardcoded Rust array (in lint_py.rs) into a top-level ruff.toml, and add ty.toml for the type checker
- Extracting all remaining pip dependencies into dedicated ci/lint/requirements.txt
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
16:01:41 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:01:52 <dergoegge> nothing from my side16:02:21 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:02:39 <sipa> Hi!
16:03:26 <sipa> We’re getting very close to the finish line. #34257 was merged. Next to review is #34023 which would be good to get into the first release still.
16:03:42 <sipa> I’ve removed some parts of the latter that are less critical, so ready for review now.
16:04:02 <sipa> That’s it for me.16:04:14 <fjahr> #topic Net Split WG Update (cfields)
16:05:12 <cfields_> nothing to report this week16:05:57 <fjahr> #topic unbundling the GUI
16:06:04 <hebasto> hi
16:06:07 <hebasto> I'm presenting this topic alone.
he provides a gist
16:06:18 <hebasto> it's a common opinion that the GUI development stuck.
16:06:23 <hebasto> but I see it a bit differently; it's in stalemate.
16:06:29 <hebasto> the current monolithic approach in the codebase, build system, release process, and publishing makes it infeasible to move forward neither in the current GUI (like adding Wayland support for release binaries) nor in new QML-based GUI.
16:06:34 <hebasto> this crisis stems from the natural antagonism between security (less dependencies) and functionality (more dependencies).
16:06:41 <hebasto> the problem with Bitcoin Core GUI has been known for quite a long time, and this attempt to find a solution isn't the first.
16:06:46 <hebasto> furthermore, the long-standing nature of this issue, combined with the separate GUI repository, led to a decline in developer focus on the GUI.
16:06:53 <hebasto> I strongly believe that it is in best interest of the current and _future_ users to shift focus on developing the GUI based on a public API (IPC, RPC etc).
16:06:59 <hebasto> of course, we have to pledge to develop and maintain such APIs basing on the best engineering practices.
16:07:04 <hebasto> as a side effect, it opens a free market for alternative GUI implementations.
16:07:08 <hebasto> the immediate action I propose is to deprecate the GUI binaries in v31.0
16:07:14 <hebasto> in light of the above, I will be shifting my personal focus accordingly.
16:07:18 <hebasto> that's all from me
Then there is more conversation about this. Read more in the full meeting in minutesFollow this link for the full meeting in minutes
Releases
Thank you for reading. Be sure 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