📝 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

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2584981169)
I renamed it to `block_reward_remaining`.

My understanding is that with merged-mining (see e.g. #33890) miners are expected to add their own outputs _after_ we give them a block template. These are typically 0 value `OP_RETURN` outputs, but - if the pool permits - they could be non-zero.

If we assume that nobody is going to patch Bitcoin Core to add outputs here (instead of downstream), then `block_reward` is accurate. For now...

However, there's still the possibility of the hypothetica
...

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2584983479)
Taken, except:
- I used stronger wording for the 8 byte guarantee
- mention that OP_0 is historically an extranonce (which hopefully goes away, see https://github.com/bitcoin/bitcoin/pull/32420)

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

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2584984800)
This should be better now.

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3606701833)
I got rid of `ExtractCoinbaseTemplate` in favour of having `CreateNewBlock()` produce the `CoinbaseTemplate` right as it constructs the dummy template. It's then stored on the `CBlockTemplate` as suggested by @ryanofsky.

Since "coinbase" refers to the scriptSig of the coinbase _transaction_, I renamed some things:
- `CoinbaseTemplate` -> `CoinbaseTxTemplate`
- `getCoinbaseTx()` to `getCoinbaseRawTx()` (IPC clients are not affected by renames)
- `getCoinbase()` to `getCoinbaseTx()`