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.
The merge with the most review this week is the wallet fee ceiling. -maxtxfee is a total fee, an amount, and the default is 0.10 BTC. The wallet was using that amount as the upper bound on the fee rate. #29278 adds-maxfeerate, a rate, default 0.10 BTC/kvB (10,000 sat/vB). The wallet will not create a transaction above that rate, and broadcast rejects one the same way.
The next merge by review activity is a Guix time-machine update. On riscv64, guix shell failed because python-lief 0.17.5 does not support that system. The pin moves to Guix 60f6956a, and that build works again.
Thursdayโs #bitcoin-core-dev meeting, chaired by abubakarsadiq, went through the working groups, a mutation-testing site, and a proposal for automated review on pull requests. In the channel, fanquake tagged v32.0rc3.
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.
Wallet: Add
maxfeeratewallet startup option by ismaelsadeeqAbubakar Sadiq Ismail (ismaelsadeeq) merged the fix for #29220.
-maxtxfeestays the absolute cap on the fee of one wallet transaction (default 0.10 BTC, and it still lives under debug/test options).-maxfeerateis a wallet startup option, in BTC/kvB. The default isCFeeRate{COIN / 10}, 0.10 BTC/kvB, 10,000 sat/vB.CreateTransactionInternalalready refused a fee abovem_max_tx_fee. It now also refuses whencurrent_feeis abovem_max_tx_fee_rate.GetFee(tx_vsize). That error isMAX_FEE_RATE_EXCEEDED. The absolute cap still returnsMAX_FEE_EXCEEDED.Broadcast takes both limits.
SubmitTxMemoryPoolAndRelaypassesm_max_tx_feeandm_max_tx_fee_rateintobroadcastTransaction. The node test-accepts the transaction, then fails if the base fee is above-maxtxfee, or above what-maxfeerateallows for the transactionโs vsize. The strings are split. An absolute-fee failure is โFee exceeds maximum configured by user (maxtxfee)โ. A rate failure is โFee rate exceeds maximum configured by user (maxfeerate)โ.Startup treats the two options differently.
-maxfeeratebelow-minrelaytxfeeis an error, so the wallet cannot be configured to build transactions that will sit under the relay floor.-maxtxfeeset so that a 1 kvB transaction at that absolute fee would be under-minrelaytxfeeis a warning: some transactions at the relay floor will not fit under the absolute cap, and the wallet will refuse to create them.guix: Update time-machine to 60f6956aeffa7f30285745bd0ea615e9acfc74f8 by hebasto
Hennadii Stepanov (hebasto) fixed #36232. On master, a Guix build on a RISC-V host failed withpackage python-lief@0.17.5 does not support riscv64-linux. The unsupported package is an indirect dependency.python-liefpulls inpython-scikit-build-core, which pulls inpython-cattrs, which pulls inpython-msgspec.python-msgspechad(supported-systems (list "x86_64-linux" "aarch64-linux")).
The time-machine commit is Guix60f6956aeffa7f30285745bd0ea615e9acfc74f8. That includes Guix commitb35905695afd, which updatespython-msgspecand drops the system allowlist. Along with that pin,git-minimalgoes from 2.52.0 to 2.54.0,linux-headersfrom 6.1.166 to 6.1.172,python-lieffrom 0.17.5 to 0.17.6, andpython-minimalfrom 3.11.14 to 3.12.12.python-liefandnsis-x86_64also pull in packages whose tests fail when they are built natively on riscv64:python-psutil,python-pytest-xprocess, andpython-shthroughpython-lief, andpython-psutilthroughnsis-x86_64. Those tests are skipped for now.
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.
net: always complete all initial private broadcast connections by andrewtoth
Andrew Toth (andrewtoth). Open, not a draft, mergeable, on the 32.0 milestone. This is the one to read while
v32.0rc3is out and milestone 84 still has open pull requests. It is an alternative to #34707.Private broadcast is supposed to open three connections. If the node stops once the transaction shows up in its own mempool, or once the transaction is a mempool conflict, the missing connection is itself a signal. An observer who can see which connections completed can line that up with acceptance. The same class of timing leak is described on #34707 and on #29415.
This PR keeps the three initial sends. A transaction that comes back, or that conflicts in the mempool, is
MarkResolvedrather thanRemove, so the node does not treat that as โstop talking.โ Disconnects are tracked, and a retry has to go throughTryGrantRetry, so a stale failure does not turn into an extra connection on top of the original three.always send 3 times regardless if the tx is received in our mempool or is otherwise invalid
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
--- Topic 1: Fuzzing ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: I'm not sure if marcofleon is here, but no update from my side
๐บ๐ฎ๐ฟ๐ฐ๐ผ๐ณ๐น๐ฒ๐ผ๐ป: no update this week
๐บ๐ฎ๐ฟ๐ฐ๐ผ๐ณ๐น๐ฒ๐ผ๐ป: possibly next
--- Topic 2: Kernel ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #topic Kernel WG Update (sedited)
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: I think @sedited is not here, so I will move on.
--- Topic 3: Benchmarking ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #topic Benchmarking WG Update (l0rinc, andrewtoth)
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: nothing from my side, but want to present something next week
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: I haven't had an update in this WG in a while. I think I can be removed as lead.
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: I will still actively review speedup PRs and benchmark, but I don't really have regular updates to give.
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: alright, if l0rinc also has no update, it can be archived.
--- Topic 4: QML GUI ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #topic QML GUI WG Update (johnny9dev)
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Pseudorandom has completed a comprehensive overhaul of the UX
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Its looking good and were close to a design we think will work for release
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Will start getting more feedback on it.
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: If anyone is interested in trying its in the qt6 branch of the project
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: That's all for this week
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: thanks @johnny9dev
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: are there pre-built bins johnny9dev?
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: willcl-ark: by the end of the day bitcoincore.app will have them
--- Topic 5: QA / mutation testing ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #topic QA WG Update (brunoerg)
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: I've been working on a new project which is a collaborative mutation testing platform (https://mutanthub.space/). I've noticed that we have people using different tools and approaches to create mutants, different PRs addressing mutants (some overlaps), etc.
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: So the idea of this new platform is that everything is centralized there and it becomes more collaborative.
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: Anyone can submit surviving mutants, reproduce and evaluate them.
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: For every surviving mutant, people can claim that a commit or PR kills it (so people can test it and/or avoid overlaps), as well as we can have discussions about mutants there.
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: In the coming days, I will probably shutdown https://bitcoincore.space and https://secp256k1.space and centralize everything on mutanthub.
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: feedback is welcome
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: that's all
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: @brunoerg whats the process of submitting mutants?
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: e.g. you can open any file from our source code (at https://mutanthub.space/projects/bitcoin/bitcoin/code), click on a specific line and suggest a mutant. Me as admin of the platform or any other people that wants to help in this process have to approve it (just to avoid trolls).
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: we also have a feature that me and selected people can do bulk import from a json file.
๐ฑ๐๐
๐๐ด: The killed mutants are the ones where a fix has been pushed to the project?
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: killed mutants are the ones that are detected by any of our tests
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: considering the tests at the same commit point from where that mutant was created
๐ฑ๐๐
๐๐ด: ah i see, thanks for sharing it looks awesome
--- Topic 6: 32.0 milestone ---
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: Anything else to discuss?
๐ฑ๐๐
๐๐ด: Maybe just an ask there's still some items on the 32.0 milestone, it would be helpful if anyone has extra hands to look thee
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: https://github.com/bitcoin/bitcoin/milestone/84
--- Topic 7: fuzzamoto ---
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: would people find it helpful if they could tag some sort of bot or add a label that says they want a fuzzamoto build on their PR (assuming fuzzamoto covers the code in the first place)
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: eugenesiegel remind me where is there a spot to look at scenarios covered
๐๐๐ถ๐ฐ๐ธ๐ถ๐ฒ๐-๐: eugenesiegel: sounds useful to me
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: instagibbs: scenarios here: https://github.com/oss-garage/fuzzamoto/tree/master/fuzzamoto-scenarios/bin but the ir scenario covers most of the p2p stuff
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: I can vibe-code a bot ppl can ping and make it as un-invasive as possible, that's all from me
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: instagibbs: no watering hole
--- Topic 8: AI review ---
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: I'm wondering if there'd be interest in a limited trial of automated AI reviews on PRs. I've already been testing this in my mirror of bitcoin/bitcoin, and I feel the results are useful enough. If there is interest, I think we could start on PRs coming from contibutors outside the frequent-contributor group.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: could we start with allowing people to call it in for their PR, so people can sample it
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: My suspicion is that some (or all) PRs arrive with LLM assistance or review in some capacity, and that human reviewers will then download the branch and make another llm-assisted first pass review. An automated review could do some of that initial work once and make the findings available to everyone/the original author.
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: instagibbs: that could also be an approach
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: can we make it so that another person can't invoke it on your own PR if it's opt-in?
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: If you want to see what the reviews are like first, then you can check new/recently-synced PRs here: https://git.fish.foo/bitcoin/bitcoin there should be a comment from "ralph" after some time with a review
๐๐ฎ๐ป๐ฐ๐: I think that would be interesting upon request
๐ฑ๐๐
๐๐ด: what model is it using?
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: I have to run out now, but will read all following messages when I get back. Happy to provide more details/links to bot code/prompts etc if folks want
๐๐ถ๐น๐น๐ฐ๐น-๐ฎ๐ฟ๐ธ: I had codex make a crazy "how it works" chart which is here, and has the models in use for each agent/pass: https://github.com/willcl-ark/nix/blob/master/pkgs/forgejo-review-bot/README.md
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: I think most of the value of LLM reviews is still having it be distilled by experienced contributors. So just posting the LLM output on a PR doesn't add much value IMO.
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: andrewtoth_: +1, I think it can be noise sometimes, so a dev should review the LLM reviews and post them.
๐ฎ๐ฏ๐๐ฏ๐ฎ๐ธ๐ฎ๐ฟ๐๐ฎ๐ฑ๐ถ๐พ: #endmeeting
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: I think status quo could be greatly helped, especially in terms of new contributors, I'm not sure what the right system is but I am not sure everyone pretending to not meat proxy is the right way. Could we give willcl-ark a long leash to try something on a trial period and adapt as we go? something to discuss i guess
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: Obviously we wouldnt want multiple instances rampaging around
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: I think maybe new contributors are the least likely to benefit from non-distilled review output. LLM reviews are fuzzy and will generally always return a bunch of "issues" with the code that can be "improved". It still takes a human to tell it when to stop, and newer contributors won't know which threads to pull and which are false positives/noise.
๐๐ฎ๐ป๐ฐ๐: less frequent contributors does not necessarily mean less skilled, but good point.
๐๐ฎ๐ป๐ฐ๐: I guess maybe the original suggestion of outside the frequent-contributor group is better than new
๐๐ฎ๐ป๐ฐ๐: anyway, I think something on request is interesting since there seems to be a lot of unknowns, so a trial like that would be nice
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: there's a whole spectrum of things we could do, we are not beholden to 2025 processes "just because".
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: andrewtoth_ Goose team at spiral does this
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: https://goose-docs.ai/blog/2026/07/30/issues-are-the-new-prs/
๐บ๐ฎ๐ณ๐น๐ฐ๐ธ๐ผ: willcl-ark: I am not sure about directly putting the LLM review in the main repo. My hope is still that the repo discussions are from humans for humans. I want to read comments written in the indidual voice and language of the human author. But seeing the share of monotone claude-speak in the repo today, maybe that ship has sailed :(
๐บ๐ฎ๐ณ๐น๐ฐ๐ธ๐ผ: My recommendation would be to add an anchor link to it (https://github.com/willcl-ark/nix/pull/1), so that it is easier to jump to it, for anyone who wants to, and also easy to ignore for anyone who does not want to.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: I would definitely say that the author isn't liable to respond to the review, like they are in general required to respond to humans
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: is the author required to respond to a human copy-pasting llm output though
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: I think adding this review to corecheck.dev or similar is better than having it in the main repo. That way it can still be pointed to when useful.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: eugenesiegel no, which is why I think status quo is already bad
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: andrewtoth_ I feel few people check corecheck
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: andrewtoth_: you "can't", but you can guess I suppose
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต_: if it's people I've met, then I assume they are the ones copy-pasting. But otherwise I assume it's a bot behind the avatar.
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: I like the idea of extending corecheck in a non-invasive, opt-in way with careful AI review - it's a lot easier to instruct new contributors to just check that instead of reexplaining the same concepts.
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: My concern is that those reviews will be very opinionated/centralized by whoever writes the prompts, so we should probably have our preferences documented in Core
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: and the code review prompt be something simple like "review this PR based on locally available docs" or if we want to force deeper work: 1) create an issue from this PR 2) implement this issue 3) compare these two implementations and add comments based on their differences
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: But it would help reviewers a lot if the basics were already covered by robots (the bot could even ACK when it thinks there are no blockers) - given that human review is even more of a bottleneck than ever...
๐บ๐ฎ๐
๐ฒ๐ฑ๐: happy to add AI review page to Corecheck if people think it's useful.
๐๐ฎ๐ป๐ฐ๐: corecheck.dev is pretty nice for frequent contributors that know about the dashboard. New people are probably not going to look at it, even if the PR says look over there.
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: drahtbot could automatically convert to draft for new contributors if the AI review finds any blockers - with a response on how to mitigate the problem
๐น๐ฌ๐ฟ๐ถ๐ป๐ฐ: if we end up using AI review, they should combine outputs from multiple models, not just the cheapest ones - which will likely cost thousands of dollars per month
๐ธ๐ฎ๐ป๐๐๐ฟ๐ฒ: instead of having people donate AI output tokens, they should donate AI API keys to specific developers who can prompt better and burn those tokens for more useful outputs.Read the full meeting
Releases
v32.0rc3was tagged 2026-10-01 by fanquake. Signed git tag (fbdd0f96, commit2633a1de). Message: "Bitcoin Core 32.0 release candidate 3". No GitHub Release page. The bump is #36400, on top of the backports in #36300.
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