📝 glozow opened a pull request: "build: bump CLIENT_VERSION_MAJOR to 29"
(https://github.com/bitcoin/bitcoin/pull/32041)

💬 glozow commented on pull request "build: bump CLIENT_VERSION_MAJOR to 29":
(https://github.com/bitcoin/bitcoin/pull/32041#issuecomment-2718194037)
Missed for branch-off, my bad. Thanks @fanquake

👍 fanquake approved a pull request: "build: bump CLIENT_VERSION_MAJOR to 29"
(https://github.com/bitcoin/bitcoin/pull/32041#pullrequestreview-2678861797)
ACK a3f0e9a4336a57440615efb352793fe131079487

🚀 fanquake merged a pull request: "build: bump CLIENT_VERSION_MAJOR to 29"
(https://github.com/bitcoin/bitcoin/pull/32041)

💬 m3dwards commented on pull request "Require sqlite when building the wallet":
(https://github.com/bitcoin/bitcoin/pull/31961#issuecomment-2718208216)
ACK 36b6f36ac4724cb2c9ed0e25314c3bbf55e4ebb8

💬 yancyribbens commented on pull request "Fee Estimation via Fee rate Forecasters":
(https://github.com/bitcoin/bitcoin/pull/30157#discussion_r1991732669)
Ok, it's just that you are using `MEMPOOL_FORECAST_MAX_TARGET + 1` as the positional argument for `Confirmation target %s` which doesn't seem right, but maybe I'm mistaken.

💬 yancyribbens commented on pull request "Fee Estimation via Fee rate Forecasters":
(https://github.com/bitcoin/bitcoin/pull/30157#discussion_r1991741915)
Oh, you mean to say 25th percentile of `DEFAULT_BLOCK_MAX_WEIGHT`

⚠️ fjahr opened an issue: "Script Validation Performance Improvement Tracking Issue"
(https://github.com/bitcoin/bitcoin/issues/32042)
This is a tracking issue for a couple of improvements targeting performance of script validation that are closely related. The topic was [discussed at CoreDev in February 2025](https://gist.github.com/fjahr/b020a16255f044ef62c48e9adf18881a) as well.

Benchmarking
- Pending: Benchmarking across different available threads ([using benchkit](https://github.com/bitcoin-dev-tools/benchkit))
- https://github.com/bitcoin/bitcoin/pull/31689

Schnorr Batch Validation
- https://github.com/bitcoin-core/sec
...

💬 maflcko commented on pull request "contrib: Add deterministic-unittest-coverage":
(https://github.com/bitcoin/bitcoin/pull/31901#issuecomment-2718268595)
Anything left to do here?

The goal here is to add the contrib tool, not to fix all non-determinism in all tests. Especially, if they happen only on macOS, I can't really fix it myself anyway, since I don't have macOS. Ideally this is done in a follow-up.

There are three acks, two of which indicate to have tested the changes.

👍 hebasto approved a pull request: "Require sqlite when building the wallet"
(https://github.com/bitcoin/bitcoin/pull/31961#pullrequestreview-2678966319)
re-ACK 36b6f36ac4724cb2c9ed0e25314c3bbf55e4ebb8.

💬 hebasto commented on pull request "depends: remove `NO_HARDEN` option":
(https://github.com/bitcoin/bitcoin/pull/32038#issuecomment-2718326026)
Concept ACK.

💬 maflcko commented on pull request "removed duplicate call to GetDescriptorScriptPubKeyMan":
(https://github.com/bitcoin/bitcoin/pull/32023#issuecomment-2718335838)
See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#committing-patches

💬 polespinasa commented on pull request "wallet, rpc: deprecate settxfee and paytxfee":
(https://github.com/bitcoin/bitcoin/pull/31278#discussion_r1991801639)
> Good idea for a follow up PR, a section on removing a feature will be nice.

@ismaelsadeeq I think you might want to take a look at this PR https://github.com/bitcoin/bitcoin/pull/30142

👍 ryanofsky approved a pull request: "depends: patch around PlacementNew issue in capnp"
(https://github.com/bitcoin/bitcoin/pull/31998#pullrequestreview-2679035874)
Code review ACK 1ef22ce3351708bdd294d675f818880b7c93fffc. Confirmed patch is identical to one merged upstream. Only change since last review was tweaking the file paths and commit data in the patch.

💬 TheCharlatan commented on pull request "refactor: Improve assumeutxo state representation":
(https://github.com/bitcoin/bitcoin/pull/30214#issuecomment-2718373984)
Reading through commit a35a2a05887202de8c49727b6ea9166bf5f1a6f2 I am asking myself if with the addition of `m_target_blockhash`, the state of `m_validity` can just be computed on the fly without having to lug around and assert its state. For tracking the change in validity to `INVALID` once the tip reaches the target block the historical chainstate, could the presence of the `m_target_utxo_hash` (similar to how the belt-and-suspenders check is done later on) be checked instead? And for the curre
...

👍 TheCharlatan approved a pull request: "depends: patch around PlacementNew issue in capnp"
(https://github.com/bitcoin/bitcoin/pull/31998#pullrequestreview-2679065785)
ACK 1ef22ce3351708bdd294d675f818880b7c93fffc

🤔 fjahr reviewed a pull request: "doc: add guidance for RPC to developer notes"
(https://github.com/bitcoin/bitcoin/pull/30142#pullrequestreview-2679057659)
ACK 40ac07ef45f6de0ac6a13e34797387a6ee140de9

Good addition!

💬 fjahr commented on pull request "doc: add guidance for RPC to developer notes":
(https://github.com/bitcoin/bitcoin/pull/30142#discussion_r1991821751)
nit: Below doesn't talk about reviewing afaict

``` suggestion
A few guidelines for modifying existing RPC interfaces:
```

🤔 polespinasa reviewed a pull request: "doc: add guidance for RPC to developer notes"
(https://github.com/bitcoin/bitcoin/pull/30142#pullrequestreview-2679075922)
Concept ACK.

I would also add some indications on how to deprecate RPCs (https://github.com/bitcoin/bitcoin/issues/31980).

See https://github.com/bitcoin/bitcoin/pull/31278 as an example of a try to deprecate an RPC and the discussions held about the procedure.

📝 l0rinc opened a pull request: "[IBD] - Tracking PR for speeding up Initial Block Download "
(https://github.com/bitcoin/bitcoin/pull/32043)
During the last Core Dev meeting, it was proposed to create a tracking PR aggregating the individual IBD optimizations - to illustrate how these changes contribute to the broader performance improvement efforts.

## Summary: **18%** full IBD speedup
We don't have many low-hanging fruits anymore, but big speed improvements can also be achieved by many small, focused changes.
Many optimization opportunities are hiding in consensus critical code - this tracking PR provides justification for why
...