This week in Bitcoin Core - #31
The final installment of ASMap has been 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. Here’s what I found notable.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, 19 changes were merged. Here are some I thought were interesting from this week.
build: Embedded ASMap [3/3]: Build binary dump header file by fjahr
This is the final part in a 3-part series of pull requests to add ASMap to the binary. If you’re not familiar with Autonomous Systems, I highly recommend reading up on them. The goal of this change is to map which Autonomous System an IP address belongs to. If Bitcoin Core knows which Autonomous System IPs belong to, then it can better avoid being eclipse attacked.
This change being added to Bitcoin Core helps the network avoid being partitioned attacked by isolating users to a few Autonomous Systems.
To read more, I recommend this websiterpc,net: Add private broadcast RPCs by andrewtoth
Recently, there was a change that was merged that allowed Bitcoin Core the ability to send transactions over a short-lived Tor or I2P connection. This change added additional privacy for the Bitcoin Core node operator.
But there was no RPC to track the state of those transactions, which is what this PR is accomplishing. This PR adds the getprivatebroadastinfo and abortprivatebroadcast. What those RPC’s do is self-explanatory by the name.
This change adds observability to the inner workings of private broadcast and its state.fees: enable
CBlockPolicyEstimatorreturn sub 1 sat/vb fee rate estimates by ismaelsadeeq
This is straightforward to change to update the CBlockPolicyEstimator to accept sub-1 sat/vbyte transactions. You may be wondering why this change came so late, sub 1 sat/vbyte summer has been over for a while. But this PR was opened on Aug 15th 2025. Nonetheless, having this functionality is still useful since getting a transaction mined into a block still requires a low sat/vbyte rate.
This change makes the Bitcoin Core fee estimator more accurate when it comes to blocks that might have a substantially low fee rate.
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.
The wallet.dat-journal file is SQLite’s hot journal file. This file is either deleted, truncated, or has its header zeroed when a database transaction is committed. However, in
restorewallet, we are assuming that sqlite decided to delete the journal file even though it may have truncated or zeroed its header instead.This PR changes
SQLiteDatabase::Close()to remove the journal file if it is 0 bytes, or if the header (first 28 bytes) is all 0’s. Otherwise, it leaves the file untouched
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
16:01:33 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:04 <dergoegge> no update16:02:17 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:02:23 <l0rinc> Benchmarked the costmodel for #34138 on several different platforms
16:02:52 <l0rinc> Had lots of reviews on the #34280 - thanks, keep them coming
16:02:57 <l0rinc> that’s it from me - andrewtoth?
16:03:07 <andrewtoth_> Lots of great review on #34165, thank you! Had others do more benchmarking on #31132. Thanks!
16:04:02 <fjahr> andrewtoth: anything else to add?
16:04:24 <andrewtoth_> that was it16:04:28 <fjahr> #topic Silent Payments WG Update (Novo)
16:04:52 <Novo> It’s decided now that we will be limiting the max number of sp outputs in a tx
16:05:18 <Novo> The current value is 1000. It is not part of the BIP yet and still being debated
16:05:32 <Novo> With this, we can solve the worst case scanning problem
16:05:48 <Novo> I also experimented with a parallel scanning approach https://github.com/bitcoin-core/secp256k1/pull/1765#issuecomment-3907225436
16:06:17 <Novo> Works pretty well, but might require changes to the API
16:06:59 <Novo> In practice, users should not need to do this since worst case scanning time with a maximum of 1000 outputs is in seconds
16:07:29 <Novo> Hence, there’s not a lot of support to modify the API to support parallel scanning but we will see
16:07:42 <theStack> for the proposed K_max protocol change, I’m planning to open a BIP-352 PR today or tomorrow, with proper test vectors; no one has opposed the K_max=1000 suggestion, but different suggestions could still be made in that PR
16:07:56 <Novo> Nice theStack
16:08:17 <Novo> Nothing else to add16:08:31 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:08:37 <sipa> We’re getting very close with cluster mempool. #34023 was merged, and my last remaining PR is #34616 which I’d like to see in. There are a few more follow-ups like extra tests, RPC output, optimizations, and possible interaction with mining (to decide when to wake a waiting miners / cache blocks), but I think those aren’t essential for feature freeze.
16:09:13 <sipa> That’s it for me.16:10:24 <fjahr> #topic v31 feature freeze
16:10:56 <fjahr> Anything to be suggested to be added or removed? Anything making a push back necessary?
16:11:39 <andrewtoth_> https://github.com/bitcoin/bitcoin/milestone/74
16:12:03 <fjahr> andrewtoth: Thanks, I was just looking for it :)
16:13:30 <fjahr> It’s still a pretty long list, I didn’t have time to go through it yet. Any comments?
16:13:39 <fjahr> Otherwise, please review!
16:13:49 <fanquake> I don’t think there’s anything that would require pushing back. Things just need review. Plenty of double-ups where it’s the bug report + PR both tagged.
16:14:00 <fanquake> Mostly bug reports for bugs introduced in this cycle.16:15:02 <fjahr> #topic Bump default -dbcache setting? (sipa)
16:16:02 <sipa> Hi, I’ve been thinking about this for a while, and it seems to me that the default dbcache setting (450 MiB) is a bit outdated for most systems these days.
There was a decent amount of conversation on this topic read the meeting in minutes for the full detail16:38:50 <fjahr> #topic Embedded asmap release todos (e.g. https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2826579455) (fjahr)
16:38:51 <l0rinc> I’ll push a PR for that today, thanks for the feedback. To be clear, should we revert to a lower value after IBD or should we choose values that make sense regardless (excluding the barrowed mempool 300 MB)?
16:39:00 <fjahr> I didn’t have time to prepare anything for this but since it came up and might be relevant for the wider group, I thought I would make everyone aware of the ideas in the comment thread there.
16:39:08 <fjahr> tldr; the ideas are: moving the asmap-data repo into bitcoin-core org, letting participants of the collaborative runs sign their results and transcript with the necessary script and place for sharing, sharing the raw data before processing, notifying users of an older asmap data (potentially only after default).
16:39:12 <darosior> l0rinc: in my opinion this should be a separate improvement.
16:39:16 <fjahr> Note that these ideas are in addition to the suggested process already described here: https://github.com/bitcoin/bitcoin/blob/master/doc/asmap-data.md
16:39:23 <fjahr> Anything that people would like to add or comment on there? I will collect and track them in the asmap issue.
16:40:16 <sipa> moving asmap-data to bitcoin-core org makes sense, as does having some kind of attestation process for collaborative asmap creation participants, effectively signing off on “i ran kartograf with these settings at this point in time, and obtained this”
There was a decent amount of conversation on this topic read the meeting in minutes for the full detailTo read the full logs, be sure to check out the meeting in minutes
Releases
No releases this week
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