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.
Thursday was feature freeze for 32.0. stickies-v even had to PSA it mid-meeting. Then this morning, while the freeze was still warm, ismaelsadeeq merged mempool-based fee estimation.
For years estimatesmartfee stared at confirmation history and ignored the mempool sitting right there. Empty mempool, stale high estimate, you overpay, coins don’t come back. The new estimator looks at the top block of the mempool and takes a percentile, 75th if you’re economical, 50th if you’re conservative, but only to lower what the old Block Policy Estimator already said. A miner stuffing junk into your mempool cannot pump the fee. Historical numbers from the PR: about 29% less overestimation, and a 73% success rate with 0% overestimation.
cfields asked for a freeze exception on vectorized chacha20. The room said 33.0 is fine. Co-author credit also ate a chunk of the meeting. More on that below. And last week’s “please review this” txindex PR actually merged, so the index is on a diet.
Merged PR’s
Every week, several changes are officially added to Bitcoin Core. This week, multiple changes were merged. Here are some I found interesting this week.
txindex: hash keys and pack positions to reduce disk usage by andrewtoth
Last week I asked y’all to review this. This week it merged.
The current txindex uses the full 32-byte txid as keys, which is about 66 GB on mainnet today. andrewtoth switched to a 5-byte salted siphash prefix and packed the tx position into the key, same trick as txospenderindex. That drops the index to about 26 GB — less than half. Collisions happen (he measured hundreds of thousands of 2-way ones on mainnet, plus a handful of 3-way and one 4-way), but the penalty is an extra disk read, a deserialize, and a hash. Lookups stayed around 0.2ms.
Existing nodes can keep the old entries and append the smaller ones, or wipe
indexes/txindexand reindex. Indexing was faster on his machine too: 1h19m vs 1h50m. Follow-up if you run pruned: #36002 wants to make txindex work in pruned mode.fees: Introduce Mempool Based Fee Estimation to reduce overestimation by ismaelsadeeq
ismaelsadeeq (Abubakar Sadiq Ismail) has been chasing #27995 for a while. This is the version that landed, the morning after feature freeze.
The trick is the one-way ratchet. The mempool estimator builds a block template, takes that percentile feerate, and is only allowed to cut the Block Policy Estimator’s number. The old estimator is not gameable the way a raw mempool snapshot is, so a Finney-style miner stuffing your mempool cannot raise what Core recommends. Underestimation is the safer failure mode now that RBF/CPFP actually work (TRUC, ephemeral anchors, cluster-size-2 package RBF): bump later; overpay and the extra fee is gone.
It also refuses to trust your mempool unless the last 6 blocks look like you saw most of what miners saw — mempool tx weight removed vs block weight above 75%. Estimates are cached at most every 7 seconds while the tip is unchanged. The remaining miss is a sudden inflow the old estimator is slow to notice, which the PR puts at about 26% of the time. Live stats: https://bitcoincorefeerate.com/stats
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.
validation: prefetch blocks while connecting by l0rinc
l0rinc called this out in Thursday’s meeting. Feature freeze already happened, but he and others treated this class of change as an optimization, not a feature. It shines on HDDs.
Block reading and decoding currently happen before block connection, even though loading is mostly I/O-bound and validation is CPU-bound.
This is a follow-up to #35295, which parallelized input prevout fetching during block connection.
Fix: Route block loading through a block fetcher, add synchronous 1-block read-ahead, then move reads to a lazily started single-worker pool that persists across activations. Queue up to 2 reads on that worker. This PR deliberately keeps 1 reader and a fixed queue size of 2 to avoid concurrent disk reads and limit the initial interface.
Credit: The idea comes from bitcoindev1337, who had already implemented a similar solution and reported comparable results.
On an HDD reindex-chainstate that was ~8.6 hours → ~6.3 hours (about 1.37x). SSD IBD still picked up ~15%. Reviewers wanted, and the co-author discussion in IRC started on this PR, so maybe don’t surprise fanquake with a Co-authored-by unless he actually wrote code.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
---- Topic 1 ---
stickies-v: #topic Fuzzing WG Update (dergoegge, marcofleon)
dergoegge: no update
--- Topic 2 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35889 was merged, is a similar follow-up #36032
l0rinc: #35531 was also merged, #36002 is a follow-up to make it work for pruned nodes
l0rinc: and as mentioned before here, #36000 was opened since
l0rinc: it shines on HDDs especially
hodlinator: nice!
l0rinc: as mentioned here before, I'm investigating if we can extend it in a future PR with different thread context-independent CheckBlock validations
l0rinc: sipa: you mentioned you were thinking of redesigning validation to be multitreaded, does this interfere with that?
stickies-v: wdym with "different thread context-independent CheckBlock validations"?
sipa: l0rinc: not pursuing that right now
l0rinc: #36000 loads the blocks on different threads, so we can do some of the check (the ones that don't require extra connection context) there basically for free
l0rinc: that's it from me, thanks
stickies-v: i see, just CheckBlock on multiple threads
l0rinc: yes
--- Topic 3 ---
stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Started the first PR into the gui-qml "staging" branch at #871
johnny9dev: The idea is to reconstruct the project with clean, mergable history using everything we've learned building the project. I need to work on the description still
johnny9dev: The first 2 or 3 PR will likely be the most interesting as it will establish the core pieces (build, test, app lifecycle, and basic models)
johnny9dev: so I think that is the plan to move towards getting this upstreamed. I will give these PRs plenty of time to get review from anyone that would potentially be interested in them
johnny9dev: and i think now is a good time to get started
johnny9dev: thats all for now
--- Topic 4 ---
stickies-v: #topic QA WG Update (brunoerg)
brunoerg: no update
cfields: proposed topic: potential feature-freeze exception for vectorized-chacha20
--- Topic 5 ---
stickies-v: #topic potential feature-freeze exception for vectorized-chacha20 (cfields)
cfields: Very sorry for coming down to the wire here, but I'm curious if there's any appetite for an exception to the feature freeze for the vectorized chacha20 impl. It speeds up chacha20 by 1.5-3x (depending on platform/compiler), which is currently one of the most obvious pain points that shows up in flame graphs. I opened the PR months ago but I've been waiting to see what happened with upstream GCC (they're working on a substantial vectorization improvement that I assumed existed there while working on the PR. They've responded to my bug reports and I'm confident that the improvements will land, but haven't yet so I've decided to pivot). I'm working on a 128bit version (with l0rinc's help) that should perform better everywhere (though can be replaced with a better 256bit version once GCC gets its act together).
cfields: I can commit to spending the next week working on it if there's interest in doing some focused review for v32.
cfields: #34083
sipa: next week is a bad time for me, i don't think i can commit to reviewing
cfields: Nothing about it is urgent, it'd just be a nice speedup to ship for 32.
l0rinc: It's not technically a feature, optimizations can be considered bugfixes - I can continue reviewing
stickies-v: this looks like a cool improvement but i think it'd be equally cool to ship in 33?
cfields: Ok, wfm.
l0rinc: I'm fine with both, we have a few other optimizations lined up anyway
cfields: my fault for letting it sit there for so long.
cfields: thanks. next topic :)
stickies-v: so yeah, PSA: today is feature freeze
--- Topic 6 ---
stickies-v: should we talk a bit more about the co-authorship thing? i don't really care much about/for it but it seems to have come up a few times
stickies-v: i think one group sees it as a tool to figure out who knows the most about a piece of code/is a person to talk to, another sees it as a way to give credit / say thank you
stickies-v: oh and also it was mentioned as a way to express copyright
sr_gi: Context?
sipa: stickies-v: i was just comparing it with copyright as a bar
stickies-v: sr_gi: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-08-18#1247067 (and following days)
sipa: i see it as a way of giving credit, and the bar that sounds reasonable for that seems to roughly match the point where someome could claim cooyright
l0rinc: copyright is a bad example here: #35794: Relevant U.S. Copyright Office guidance page 5
l0rinc: > Applicants should not list an AI technology or the company that provided it as an author or co-author simply because they used it.
stickies-v: i use it when someone has contributed significant amounts of code, or in rare cases even when there was no/little code but a significant amount of architectural/design ideas that made me change course
l0rinc: I also see it as giving credit to thank people who helped in shaping the outcome. A good recent example is
Rob spent a lot of time and money on finding these, the least we can do is acknowledge his work by adding him as coauthor.
sr_gi: I've been using it myself to give credit, specially if someone else has started the work and I've picked it up later, but the base is still theirs (e.g. Gleb with Erlay)
sipa: How so? AI tools don't have copyright, and we don't add them as co-author.
sipa: So the analogy seems to work.
l0rinc: AI is tool, we don't add clang-tidy as coauthor either
l0rinc: we don't need to thank the AIs (yet)
sipa: I'm not sure if you're agreeing or disagreeing with me.
l0rinc: I think I'm mostly agreeing
dzxzg: I don't know if it's something that needs to have well-defined meaning, everyone probably uses it a little bit differently, but all use it to mean some variation of "this person helped make this change." anything more detailed would probably need to be resolved case-by-case between the author and (alleged) coauthor
sipa: My position is that you should add someone as co-author if they could reasonably claim copyright.
stickies-v: sipa: that sounds like a good heuristic to me
sipa: It's a way of giving credit, but for actually contributed code, not.ideas.
sipa: It does not imply the co-author understands the entire commit.
l0rinc: I am very much against copyright, so the analogy gives me the creeps
johnny9dev: just an fyi, I'll be making heavy use of co-authored-by in the gui-qml staging commits as I will be compressing the large history into something digestible. The co-authors will all have been involved with constructing the relevant piece in some significant way. I will make sure I only co-author the person if I believe they can speak on the functionality introduced.
l0rinc: is there a drawback to thanking people this way? What's the reason for the pushback exactly, that it's interpreted as distributing blame?
shiza: I read it was something about grants
sipa: l0rinc: ok, read it as "contributed a nontrivial piece of code of at least 5-10 lines" then
l0rinc: what the reason for avoiding it for 1-5 lines? Is it a grant-thing as mentioned?
sipa: l0rinc: i think it is weird to credit anyone who contributed ideas or helped with benchmarks or whatever, it's a collaborative project where everyone builds on one another. Authorship is a higher bar than that.
sipa: Or suggested a few single line changes.
fanquake: Yea. My pushback to #36000, was that I'd barely looked at the code, so I didn't see why I'd be a co-author
shiza: 2026-08-14 21:28:42 aj are we using co-author to mean "wrote some of the code in this commit" or "contributed to the design" these days? i thought the former, but i've seen a few cases where the latter seems to be more in play? does the distinction matter for some people's grant KPIs?
fanquake: I guess AJ was similarly confused here, #35920, about the request to be added as co-author
sr_gi: l0rinc: reading the piece that stickies-v shared I see the issue as not giving credit instead of doing so, but I haven't read the whole history
lightlike: different policies becomes a problem when people expect others to add them as coauthors (in the way they would do it to them), but the other person has a stricter policy and declines the request.
fanquake: *about the request for someone else to be added as co-author
l0rinc: "Authorship is a higher bar than that" - if someone contributed meaningfully I just add them as main author in that case, like: #35752
sipa: you can contribute a meaningful amount of code without being the main author of a commit
stickies-v: alright, i think we can wrap up on this
stickies-v: anything else to discuss?
l0rinc: thanks for the feedback
stickies-v: #endmeetingRead here for the full meeting
Releases
No releases
32.0 feature freeze was Thursday 2026-08-20. No v32.0 tag yet. Latest still v31.1 / v30.3 / v29.4.
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