🤔 janb84 reviewed a pull request: "doc, windows: CompanyName "Bitcoin" => "Bitcoin Core project""
(https://github.com/bitcoin/bitcoin/pull/32719#pullrequestreview-2916143213)
utACK 239fc4d62e73511b3ef5117706d4c5131a921955

Not tested, did a code review. PR makes a (small) change to align the "company name", in several RC files, to the name used in the installer.
Imo this is a sensible change to keep those names aligned. ✅

👍 hebasto approved a pull request: "doc, windows: CompanyName "Bitcoin" => "Bitcoin Core project""
(https://github.com/bitcoin/bitcoin/pull/32719#pullrequestreview-2916267444)
ACK 239fc4d62e73511b3ef5117706d4c5131a921955.

💬 hebasto commented on pull request "doc, windows: CompanyName "Bitcoin" => "Bitcoin Core project"":
(https://github.com/bitcoin/bitcoin/pull/32719#issuecomment-2961885996)
My Guix build:
```
aarch64
458b3244f108716a6439c79c99f50da02eeec8e980e995455727fc134630e471 guix-build-239fc4d62e73/output/dist-archive/bitcoin-239fc4d62e73.tar.gz
19e34684107ea85baf7949d341dda007849860ff4341bc5139c1dd61a37a9c48 guix-build-239fc4d62e73/output/x86_64-w64-mingw32/SHA256SUMS.part
4515f2169e10825fa02a34aebd7c928ff366ee2481b4332180cd410fe5e56031 guix-build-239fc4d62e73/output/x86_64-w64-mingw32/bitcoin-239fc4d62e73-win64-codesigning.tar.gz
20a47574d6875275812c08cbbe108696f87
...

💬 maflcko commented on pull request "index: move disk read lookups to base class":
(https://github.com/bitcoin/bitcoin/pull/32694#issuecomment-2961892641)
review ACK 029ba1a21d570f7db6c4366ec9a30a381b56d6fb 👡

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 029ba1a21d57
...

🚀 hebasto merged a pull request: "doc, windows: CompanyName "Bitcoin" => "Bitcoin Core project""
(https://github.com/bitcoin/bitcoin/pull/32719)

💬 maflcko commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#discussion_r2139659083)
needs rebase after https://github.com/bitcoin/bitcoin/pull/32719?

📝 Sjors opened a pull request: "test: round difficulty and networkhashps"
(https://github.com/bitcoin/bitcoin/pull/32725)
Both are rational numbers. Client software should only use them to display information to humans. Followup calculations should use the underlying values such as target.

Therefore it's not necessary to test the handling of these floating point values. Round them down to avoid spurious test failures.

Fixes #32515

💬 Sjors commented on issue "test: failure in `mining_basic.py` AssertionError: not(4.656542373906924E-10 == 4.656542373906925E-10)":
(https://github.com/bitcoin/bitcoin/issues/32515#issuecomment-2961959561)
#32725 should fix this

💬 Sjors commented on pull request "test: round difficulty and networkhashps":
(https://github.com/bitcoin/bitcoin/pull/32725#issuecomment-2961968599)
Note that `mining_mainnet.py` uses round difficulty values (1 and 4) so it shouldn't have this issue.

📝 scott-weeden opened a pull request: "Add initial OpenAPI/Swagger specification for Bitcoin Core RPC and REST interfaces (issue #29912) "
(https://github.com/bitcoin/bitcoin/pull/32726)

## Motivation

Currently, (almost) all clients manually implement the Bitcoin Core RPC API, which leads to:
- Accidental implementation bugs (e.g., unit mistakes such as vB vs BTC/kvB)
- Difficulty maintaining clients as the API evolves
- Increased effort to implement clients in new programming languages

There is no formal, machine-readable specification of the RPC API. Existing documentation is not sufficient for code generation or type-safe client implementations. See discussion in #
...

💬 maflcko commented on pull request "wallet, rpc: Remove deprecated balances from getwalletinfo and getunconfirmedbalance":
(https://github.com/bitcoin/bitcoin/pull/32721#discussion_r2139713359)
I think back when I deprecated this, the legacy wallet allowed for mine and watch_only dicts in the getbalances. so listing one but not the other here was confusing. however, now that descriptor wallets are required, this is no longer the case. Seems fine to remove or un-deprecate. No strong opinion.

💬 maflcko commented on pull request "wallet, rpc: Remove deprecated balances from getwalletinfo and getunconfirmedbalance":
(https://github.com/bitcoin/bitcoin/pull/32721#discussion_r2139700994)
lgtm. Seems confusing to have a single inconsistent RPC that mirrors a single field of another RPC

💬 jurraca commented on pull request "Embed default ASMap as binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#issuecomment-2962177367)
> How quickly does the data degrade?

ran some numbers, counting by the number of addresses within networks, and diff'ing month to month, the ASmap from Dec 1 to Apr 1 drifted about 5%:
```
IPv4 drift from Dec 1
Jan 1: 1.40%
Feb 1: 3.72%
Mar 1: 4.90%
Apr 1: 5.23%

IPv6 drift from Dec 1
Jan 1: 2.04%
Feb 1: 4.29%
Mar 1: 5.23%
Apr 1: 5.74%
```
Method: running `python3 contrib/asmap/asmap-tool.py diff map1.txt map2.txt` which outputs the total count of addresses changed between the t
...

📝 vasild opened a pull request: "doc: add release notes for #32425"
(https://github.com/bitcoin/bitcoin/pull/32727)
Add release notes for https://github.com/bitcoin/bitcoin/pull/32425.

💬 vasild commented on pull request "config: allow setting -proxy per network":
(https://github.com/bitcoin/bitcoin/pull/32425#issuecomment-2962235283)
> Needs release note?

Right. Done in https://github.com/bitcoin/bitcoin/pull/32727

✅ scott-weeden closed a pull request: "Add initial OpenAPI/Swagger specification for Bitcoin Core RPC and REST interfaces (issue #29912)"
(https://github.com/bitcoin/bitcoin/pull/32726)

📝 scott-weeden reopened a pull request: "Add initial OpenAPI/Swagger specification for Bitcoin Core RPC and REST interfaces (issue #29912)"
(https://github.com/bitcoin/bitcoin/pull/32726)

## Motivation

Currently, (almost) all clients manually implement the Bitcoin Core RPC API, which leads to:
- Accidental implementation bugs (e.g., unit mistakes such as vB vs BTC/kvB)
- Difficulty maintaining clients as the API evolves
- Increased effort to implement clients in new programming languages

There is no formal, machine-readable specification of the RPC API. Existing documentation is not sufficient for code generation or type-safe client implementations. See discussion in #
...

✅ scott-weeden closed a pull request: "Add initial OpenAPI/Swagger specification for Bitcoin Core RPC and REST interfaces (issue #29912)"
(https://github.com/bitcoin/bitcoin/pull/32726)

💬 vasild commented on pull request "config: allow setting -proxy per network":
(https://github.com/bitcoin/bitcoin/pull/32425#discussion_r2139847689)
What about this:

```diff
diff --git a/src/init.cpp b/src/init.cpp
index 77dc74f690..08ec964e25 100644
--- a/src/init.cpp
+++ b/src/init.cpp
@@ -1190,14 +1190,20 @@ bool CheckHostPortOptions(const ArgsManager& args) {
{"-zmqpubhashtx", true, false},
{"-zmqpubrawblock", true, false},
{"-zmqpubrawtx", true, false},
{"-zmqpubsequence", true, false},
}) {
for (const std
...

📝 ismaelsadeeq reopened a pull request: "init: make `-blockmaxweight` startup option debug only"
(https://github.com/bitcoin/bitcoin/pull/32654)
This PR updates `-blockmaxweight` startup option to be debug-only so that it will be hidden from help text.

The option is currently unlikely to be used on mainnet, after the addition of the new `blockreservedweight` option. however it can be useful for test and signet network see https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2925674473

📝 scott-weeden opened a pull request: " Add initial OpenAPI/Swagger specification for Bitcoin Core RPC and REST interfaces (issue #29912) "
(https://github.com/bitcoin/bitcoin/pull/32728)
## Motivation

Currently, (almost) all clients manually implement the Bitcoin Core RPC API, which leads to:
- Accidental implementation bugs (e.g., unit mistakes such as vB vs BTC/kvB)
- Difficulty maintaining clients as the API evolves
- Increased effort to implement clients in new programming languages

There is no formal, machine-readable specification of the RPC API. Existing documentation is not sufficient for code generation or type-safe client implementations. See discussion in #29
...