✅ fanquake closed a pull request: "index: remove unnecessary locator cleaning in BaseIndex::Init()"
(https://github.com/bitcoin/bitcoin/pull/32882)

📝 fanquake reopened a pull request: "index: remove unnecessary locator cleaning in BaseIndex::Init()"
(https://github.com/bitcoin/bitcoin/pull/32882)
Leverage locator.IsNull() to simplify ReadBestBlock() and remove
unnecessary SetNull().

💬 fanquake commented on pull request "tests: Add unix timestamp tests for OP_CLTV":
(https://github.com/bitcoin/bitcoin/pull/32229#issuecomment-3606304212)
cc @petertodd

🚀 fanquake merged a pull request: "contrib: fix manpage generation"
(https://github.com/bitcoin/bitcoin/pull/33996)

✅ fanquake closed a pull request: "wallet: don't consider unconfirmed TRUC coins with ancestors"
(https://github.com/bitcoin/bitcoin/pull/33528)

📝 fanquake reopened a pull request: "wallet: don't consider unconfirmed TRUC coins with ancestors"
(https://github.com/bitcoin/bitcoin/pull/33528)
Addresses https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3319935660

There is not an explicit check that the to-be-created wallet transaction would be within the {TRUC, normal} ancestor limits. This means that the wallet may create a transaction that violates these limits, but fail to broadcast it in `CommitTransaction`.

This appears to be expected behavior for the normal ancestor limits (and any other situation in which the wallet creates a tx that was rejected by mempool) an
...

📝 fanquake opened a pull request: "[30.x] Backports & 30.1rc1"
(https://github.com/bitcoin/bitcoin/pull/33997)
Backports:
* #32009
* #33996

💬 fanquake commented on pull request "contrib: fix manpage generation":
(https://github.com/bitcoin/bitcoin/pull/33996#issuecomment-3606431767)
Backported to 30.x in #33997.

💬 fanquake commented on pull request "contrib: turn off compression of macOS SDK to fix determinism (across distros)":
(https://github.com/bitcoin/bitcoin/pull/32009#issuecomment-3606432356)
Backported to 30.x in https://github.com/bitcoin/bitcoin/pull/33997.

💬 b-l-u-e commented on pull request "[p2p] Fix signed integer overflow in LocalServiceInfo::nScore":
(https://github.com/bitcoin/bitcoin/pull/33072#issuecomment-3606450126)
> Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.
>
>
>
> Marking as up for grabs.

I would like to continue to work on this..

💬 fanquake commented on pull request "wallet: don't consider unconfirmed TRUC coins with ancestors":
(https://github.com/bitcoin/bitcoin/pull/33528#issuecomment-3606452582)
Locally I could not run the merge script against this PR:
```bash
fatal: ambiguous argument 'refs/heads/pull/33528/merge': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
ERROR: Cannot find merge of pull request bitcoin/bitcoin#33528 on git@github.com:bitcoin/bitcoin.
```
Open/closed to re-run CI, and it seems to have the same issue.

📝 fanquake reopened a pull request: "[p2p] Fix signed integer overflow in LocalServiceInfo::nScore"
(https://github.com/bitcoin/bitcoin/pull/33072)
## Problem
The `nScore` field in `LocalServiceInfo` struct was defined as `int` (32-bit signed integer), which could overflow from `INT_MAX` (2,147,483,647) to `INT_MIN` (-2,147,483,648) when incremented by `SeenLocal()` during version handshakes. This is undefined behavior in C++ and could affect address selection logic.

## Solution
Implement saturation in `SeenLocal()` to cap `nScore` at `std::numeric_limits<int>::max()` instead of allowing overflow. This prevents undefined behavior while
...

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2584817277)
Changed locally with dummy addresses, for all networks. Will be part of the next push.

💬 l0rinc commented on pull request "stabilize translations by reverting old ids by text content":
(https://github.com/bitcoin/bitcoin/pull/33270#issuecomment-3606551517)
It worked correctly for stabilizing the transaltions - removals an moves alike. Some reviewers would prefer rewriting the logic from python to cmake, but it should work currently as-is. Reviews and reproducers are welcome.

💬 plebhash commented on issue "Memory leak when using IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3606595757)
> One thing I'm not sure about is why exactly the rust client is keeping 84 block template references.

We are conservatively keeping all templates in memory up until a chain tip update, because we could potentially receive a solution to any of them.

This might change with https://github.com/bitcoin/bitcoin/issues/33899 goes, but the limit will remain something to be configured on Bitcoin Core, and whenever `waitNext` returns `Overloaded` error, we start discarding old templates.

> Is this bec
...

💬 laanwj commented on pull request "guix: use GCC 14.3.0 over 13.3.0":
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3606601695)
Looks like `riscv64` matches `aarch64`. `x86_64` is the odd one out.
```
riscv64
c2846f9bc4a7c48e5fb09b68292cd8edb70e6be0ec5d3682b9f381c785907400 guix-build-c4da80608710/output/x86_64-w64-mingw32/SHA256SUMS.part
c2b3dce93b4dbf010e3d3654a0db9fdad198cffdc466e5a93d9c3e0be1b19b1d guix-build-c4da80608710/output/x86_64-w64-mingw32/bitcoin-c4da80608710-win64-codesigning.tar.gz
ee71b615d28df400f7a97fc19939be0687f1587307809b1d22266ffd5dc7b27e guix-build-c4da80608710/output/x86_64-w64-mingw32/bitc
...

💬 l0rinc commented on pull request "refactor: unify container presence checks":
(https://github.com/bitcoin/bitcoin/pull/33192#issuecomment-3606652654)
Now that https://github.com/bitcoin/bitcoin/pull/33629 and https://github.com/bitcoin/bitcoin/pull/33591 and https://github.com/bitcoin/bitcoin/pull/33960 were merged, I have rebased (in a separate push) and reconverted the remaining count and find instances to `contains` - see the new additions:
https://github.com/bitcoin/bitcoin/compare/d8c25aa8f726d26e1bf042342fda160f73811699..06f9097fca40023e1057eda5e108f2cc358670c1

Thanks for the reviewers so far, re-reviews would be appreciated.

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2584962979)
The latest push dropped `ExtractCoinbaseTemplate` entirely.

⚠️ ruthsigela6982-lab opened an issue: "HOW SMITH WHITE HACK SERVICE HELPED ME RECOVERED MY 5.8 BTC SUCCESSFULLY."
(https://github.com/bitcoin/bitcoin/issues/33998)
With the help of SMITH WHITE HACK SERVICE, Crypto scam victims are able to retrieve their money. I have to recommend SMITH WHITE HACK SERVICE to anyone who has fallen victim to a scam and has been looking for methods and techniques to recover their lost cryptocurrency wallets. SMITH WHITE HACK SERVICE is a reliable cryptocurrency recovery firm that assists victims in recovering their stolen cryptocurrency and offers secure solutions to protect your wallets from online scammers. I must admit t
...

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2584980106)
Taken