v31.0rc1 tagged - This week in Bitcoin Core #34
This week kevkevin takes a look at the changes merged into Bitcoin Core...
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.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, 49 changes were merged. Here are some I thought were interesting from this week.
cli: rework -addrinfo cli to use addresses which aren’t filtered for quality/recency by stratospher
This change has been in the works since 2023 and has finally been merged. If you have not been following it, here is a quick summary of what it changes.
This pull request updates the CLI -addrinfo to give back ALL known addresses instead of a subset. From version v22.0 to v30.0, the set that was given back was filtered by recency and quality. This has now changed because it does not match the logic used when selecting a peer, so this updates it to match.
If you are using an older Bitcoin node version, you will also need to use an older bitcoin-cli to succesfully use this method.rpc: allow writing UTXO set to a named pipe by theStack
Have you ever used the dumptxoutset for say AssumeUTXO?
This change makes it so that you can call the dumptxoutset RPC and then dump it onto a named pipe. This allows the dumped UTXO set to be consumed by another process.
TheStack makes use of this functionality in utxo-to-sqlite.py to directly convert the UTXO set into a sqlite file. I would say to myself that is pretty cool.
He also gives an example of how it would be used in the full PR.threadpool: add ranged Submit overload by andrewtoth
Andrew Toth was motivated to make this change when he had noticed that ThreadPool::Submit was not that efficient when multiple tasks had to be submitted at the same time.
The reason was that the Submit method must take a lock for each task. The way Andrew resolved this issue was by taking a single lock for the batch of tasks submitted. This significantly sped up ThreadPool::Submit.
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.
logging: rewrite macros to add ratelimit option, avoid unused strprintf, clarify confusing errors by ryanofsky
Rewrite log macros to fix a number of issues: lack of control over rate limiting, unnecessary strprintf calls during fuzzing, and confusing error messages when macros are called with the wrong arguments.
This PR is a refactoring and shouldn’t change externally visible behavior. Changes are described in detail in commit messages. There are also some internal improvements making previously implicit behaviors (evaluating unused format arguments, not outputting categories at certain log levels) explicit and better enforced.
Some changes here were originally part of #29256, but they should make sense on their own and simplify both PRs.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
16:01:53 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:25 <dergoegge> nothing from my side16:02:55 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:03:12 <l0rinc> nothing urgent from my side
16:03:29 <andrewtoth_> #34576 was merged. #31132 has been rebased with all split out PRs completed. Thanks everyone for your reviews and benchmarks!
16:03:33 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:03:35 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:03:42 <dzxzg2> hi
16:03:56 <andrewtoth_> I’m considering reopening #31132 as a fresh PR since there are over 500 comments and many are no longer relevant.
16:03:57 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:04:07 <andrewtoth_> That’s it from me.
16:04:29 <andrewtoth_> What’s wrong with corebot?
16:04:37 <_aj_> github rate limits probably?
16:04:44 <achow101> It’s not having a good day I guess
16:05:11 <_aj_> (at least i’m constantly getting rate limits when not logged in, for no apparent reason)
16:05:17 <fjahr> depressed from all the ai slop
16:05:20 <fjahr> johnny9dev: you wanted yours reactivated, right? Please edit the WGs wiki page, thanks!16:05:27 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:05:31 <johnny9dev> yes
16:05:36 <johnny9dev> For gui-qml I have been focused on cleaning up any dependency to the qt source code. I’ve also been working on the test coverage and automation frameworks. I am just about done with both and will be closing out the related issues on that. I will then begin PRing chunks of features next week along with Luke (epicleafies). The target features are all listed in the project’s Issues. I also plan on spending time to learn Figma Make
16:05:36 <johnny9dev> and Figma’s MCP server. I’ve seen some real world cases of it being very effective the last two weeks and need to explore this for gui-qml.
16:05:54 <johnny9dev> For gui, dergoegge asked if the test bridge would work for qt so I some time porting over the test automation bridge. It’s still a bit rough and needs some more validation/review but I started the draft on bitcoin-core/gui#933. Interested in what people think about this approach. Flakiness can be a problem initially with end to end tests so effort will need to be done to make sure it’s all solid before really moving forward with
16:05:54 <johnny9dev> something like this. Animations, process initializing, and timings can be tricky but this shouldn’t be much worse than what y’all already deal with for the bitcoind functional tests.
16:05:55 <corebot> johnny9dev: Error: That URL appears to have no HTML title within the first 32KB.
16:06:00 <kanzure> does figma export to qml?
16:06:14 <johnny9dev> you can use the mcp bridge to help translate figma to code
16:06:20 <dergoegge> johnny9dev: cool, I’ll have a look at that
16:06:59 <johnny9dev> epicleafies has been helping with qml also
16:07:25 <johnny9dev> epicleafies: can you give status?
16:08:04 <epicleafies> Yeah, I’ve finished the debug log page and am working on the proxy settings to persist
16:08:59 <johnny9dev> he also fully completed peers ban/disconnect including an end to end automated gui test with it
16:09:22 <johnny9dev> i think that will probably be the most complicated one too
16:09:26 <johnny9dev> with multiple nodes
16:10:14 <johnny9dev> i think that is all
16:11:19 <fjahr> I’m not seeing any of the other WG chairs.16:11:25 <fjahr> #proposedmeetingtopic logging system (_aj_)
16:11:25 <corebot> fjahr: Unknown command: #proposedmeetingtopic
16:11:30 <fjahr> sorry
16:11:33 <_aj_> There’s about a dozen open PRs/issues about changing the
16:11:33 <_aj_> logging API, many of which have been open for almost two years now. Here’s a table:16:11:25 <fjahr> #proposedmeetingtopic logging system (_aj_)
16:11:25 <corebot> fjahr: Unknown command: #proposedmeetingtopic
16:11:30 <fjahr> sorry
16:11:33 <_aj_> There's about a dozen open PRs/issues about changing the
16:11:33 <_aj_> logging API, many of which have been open for almost two years now. Here's a table: https://gist.github.com/ajtowns /ff6247953437270ce81998bc0f7d6739
Many of these changes seem to me to make things substantially worse for working on bitcoin node software, and at this point it feels like a denial of service attack: “oh, you disagreed with this PR? well, we’ll keep that one open as a sword of
16:11:33 <_aj_> damocles, but also, how about this slightly different PR with slightly different motivations?” which just leaves me giving what feel like endless “Concept NACKs” and getting more frustrated. There are still a couple of followups to #28318 that I’d like to get in (namely #34038, and once that’s done, switching the map of categories to an atomic bitfield), so I’d rather keep being somewhat involved,
16:11:33 <_aj_> but this is pretty exhausting. So I’d really like it if folks who are a bit more dispassionate on the issue could get involved and express opinions on whether any of the proposed changes are actually valuable/desired, and ideally for the number of open proposals to get trimmed down a lot.
16:11:35 <corebot> _aj_: Error: That URL appears to have no HTML title within the first 32KB.
16:11:36 <fjahr> #topic logging system
16:11:37 <corebot> _aj_: Error: That URL appears to have no HTML title within the first 32KB.
16:12:01 <achow101> (will debug the bot after the meeting)
16:12:26 <_aj_> (fin)16:12:54 <sipa> #proposedmeetingtopic I saw release notes editing for 31.0 moved to the wiki (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Notes-Draft), it’s probably good for everyone to have a look over that and add things that users ought to see
16:12:54 <corebot> sipa: Unknown command: #proposedmeetingtopic
16:13:09 <sipa> (not really a topic, just wanted to mention)
16:13:19 <_aj_> (did anyone actually announce the branch off happened btw?)
16:13:48 <sipa> Day changed to 12 Mar 2026
16:13:48 <sipa> 01:56:13 < bitcoin-git> [bitcoin] achow101 pushed 5 commits to 31.x: https://github.com/bitcoin/bitcoin/compare/b97abdcdf139...d3737769caac
16:14:40 <achow101> _aj_: how many major opinions on logging direction are there? 2?
16:15:03 <fanquake> 3 I think
16:15:08 <fjahr> there seem to be three PR authors
16:15:13 <fanquake> depending on the part of the codebase
16:15:24 <fjahr> (of currently active prs)
16:15:52 <dzxzg2> if it’s possible to express succinctly, what are the different goals / usecases / motivations for changing the interface?
16:16:43 <_aj_> i think there’s a few different ones about the kernel (if you have multiple validation objects running, can their logs be separated; if you have multiple loggers and one validation state, can they get different info); there’s a desire to pass different amounts of state to the Log*() functions (some or all of wallet name, category, level), and there’s sometimes a desire to have all messages have a
16:16:43 <_aj_> category (LogInfo(NET, “connected to new outbound”))
16:19:10 <fanquake> Rough count but I think there’s about ~15 different logging related refactors / PRs open at the moment
16:20:21 <dergoegge> Some of the kernel related logging questions seem worthwhile solving but idk about the naming and calling conventions (that just seems like an endless pit to pour time into)
16:21:16 <_aj_> the kernel stuff impacts the calling convention -- if you want logging from CheckBlock to go two different places, you have to pass in the two different logging systems into the LogDebug(..) call, eg
16:21:40 <sipa> what does “two different places” mean?
16:22:19 <_aj_> if you’re running two different ChainstateManager’s in the same process, and want to log the work they’re doing / the failures they have independently
16:23:36 <l0rinc> are these logging change suggestions fundamentally mutually exclusive?
16:23:40 <sipa> i’m confused about why that would be the case, or why the code in question would know about it at all
16:23:45 <sipa> so i’ll need to look at the PRs
16:23:53 <dzxzg2> l0rinc: +1
16:24:02 <_aj_> #34062 is possibly a good start
16:24:04 <corebot> https://github.com/bitcoin/bitcoin/issues/34062 | RFC: separate kernel logging infrastructure · Issue #34062 · bitcoin/bitcoin · GitHub
16:24:11 <_aj_> welcome back corebot
16:24:15 <abubakarsadiq> hi
16:24:27 <l0rinc> is this related to different wallets and processes logging to different output files?
16:25:32 <sedited> fwiw I think this is a nice to have, but the discussions and time sunk into logging as opposed to making things actually more useful seems skewed. I’d be happy with a simple albeit imperfect solution for now.
16:25:44 <sedited> l0rinc I think that is orthogonal
16:26:40 <ryanofsky> yeah i think we can easily make progress on this stuff, by just focusing on logging prs that are noncontroversial
16:28:13 <_aj_> ryanofsky: closing the near-alternatives, and just keeping the “best” of them open would be a win in my view (best==your opinion after taking feedback into account, not necessarily least-controversial/most-likely-to-be-acceptable; imo anyway)
16:29:10 <dzxzg2> https://en.wikipedia.org/wiki/Wikipedia:Content_forks#Pages_of_the_same_type_on_the_same_subject
16:30:20 <l0rinc> It seems to me the logging problems aren’t obvious to most of us, it seems to be mostly working already - can we start with listing the exact problems?
16:30:21 <fjahr> Maybe ask for review here again when there is a clear point were more feedback is needed. Hard to motivate yourself to go through the full list and find that for yourself, IMO.
16:31:43 <ryanofsky> i guess my general feeling is it is not good to spend time have meta-debates about what code should be reviewed and generally peole should just review things they are interested, and maintain prs they are interested in maintaining
16:32:25 <ryanofsky> if some progress is being blocked, but i am not aware of that happening
16:32:47 <fjahr> Seems like the details of logging can continue to be discussed after the meeting. Is there anything else to discuss that should be in the meeting?
16:32:53 <_aj_> fjahr: i think you could reasonably go through the gist above and say “this is ugly, is there really a big benefit?” or “this is much better than what we do now! i like it!” and have that be a useful contribution
16:32:54 <ryanofsky> sgtm
16:33:10 <ryanofsky> yeah i’ll take a look at the gist
16:33:22 <achow101> fjahr: topic for 31.0?16:33:37 <fjahr> #topic v31
16:33:52 <achow101> we branched on tuesday night, tagged v31.0rc1 yesterday
16:34:00 <_aj_> yay!
16:34:21 <achow101> there’s a backports pr and still a couple things in the milestone, so definitely will have a rc2
16:34:34 <achow101> any new issues to add to the milestone?
16:35:07 <achow101> also release notes draft is in the wiki
16:35:47 <janb84> Testing guide will be adressed by BOSS program / me
16:36:03 <fjahr> https://github.com/bitcoin/bitcoin/milestone/74
16:37:08 <achow101> otherwise that’s all
16:37:37 <fjahr> Any other topics?
16:37:37 <maflcko> I wanted to fix all intermittent test issues for this release, so if you are seeing any new, please let me know :)
16:37:45 <fanquake> Looks like I just saw another one
16:37:50 <fanquake> https://github.com/bitcoin/bitcoin/issues/34367#issuecomment-4048211050
16:38:03 <fanquake> (happened in the backports branch)
16:38:22 <fanquake> I assume we’ll fix all the multiprocess issues with another subtree pull?
16:38:37 <fanquake> (once the rest of the issues there are fixed)
16:38:41 <maflcko> Maybe let the functional tests run in a loop over night, this night, and see if it is still running the next morning. If not, leave an issue. (Make sure to increase --timeout-factor for smaller machines)
16:39:34 <fanquake> I don’t have a Windows machine, so someone on Windows will have to do that for that issue (maybe UCRT related)
16:40:26 <maflcko> oh, I meant in general, to see if *all* dev machines and platforms can run the tests smoothly
16:40:48 <fanquake> Yea sure, will be running
16:40:53 <maflcko> nice, thxReleases
https://github.com/bitcoin/bitcoin/tree/v31.0rc1
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