📝 eval-exec opened a pull request: "torcontrol: Limit reconnect timeout to max seconds and log delay in whole seconds"
(https://github.com/bitcoin/bitcoin/pull/31979)
This PR introduces a maximum reconnect timeout of 600 seconds (10 minutes) to prevent excessive delays in reconnection attempts. It also updates the log message to display the retry delay in whole seconds for better readability.

💬 eval-exec commented on pull request "torcontrol: Limit reconnect timeout to max seconds and log delay in whole seconds":
(https://github.com/bitcoin/bitcoin/pull/31979#issuecomment-2696734781)
I'm working on fixing the CI and would like to kindly invite @laanwj to review this PR. Thank you!

💬 Sjors commented on pull request "Drop testnet3":
(https://github.com/bitcoin/bitcoin/pull/31974#issuecomment-2696820588)
Will rebase after #31649 lands.

💬 hodlinator commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1979023367)
> Can we explicitly list out which things to take from the output?

While testing #31969 and using `dumptxoutset` I didn't feel the need for documentation on individual fields as long as there are prior `m_assumeutxo_data`-entries. If we keep `gettxoutsetinfo` though, the output seems to map less directly, so in that case I agree listing them might be useful.

💬 Sjors commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1979028647)
`dumptxoutset` was designed for this task (originally a contrib bash script), so it seems better to use it.

💬 willcl-ark commented on pull request "Add assumeutxo chainparams to release-process.md":
(https://github.com/bitcoin/bitcoin/pull/31940#discussion_r1979042477)
Updated to use `dumptxoutset` in 02fae3363511e96a76ff64a4513c7a7e8d8d4403

💬 Sjors commented on pull request "kernel: pre-29.x chainparams and headerssync update":
(https://github.com/bitcoin/bitcoin/pull/31978#discussion_r1979074753)
On my existing node `du -h` returns 671G for the blocks and 12G for the chainstate.

💬 fanquake commented on pull request "doc: update fuzz instructions when on macOS":
(https://github.com/bitcoin/bitcoin/pull/31954#discussion_r1979092800)
`no_warn_duplicate_libraries` isn't an lld option, so this can be dropped.

💬 fanquake commented on pull request "doc: update fuzz instructions when on macOS":
(https://github.com/bitcoin/bitcoin/pull/31954#discussion_r1979096453)
Rather than adding text that repeats the code below, we could just say something like: "Using lld is required to due to issues with Apples `ld` and LLVM".

💬 Sjors commented on pull request "kernel: pre-29.x chainparams and headerssync update":
(https://github.com/bitcoin/bitcoin/pull/31978#issuecomment-2696958623)
I did a mainnet sync using 4475d0babc070a19f3a0ac472304a8c9b87b87d7 and `-assumevalid=0` which worked. I verified the chain work for the new assume valid block, as well as the `getchaintxstats` result and `headerssync-params.py`.

✅ fanquake closed an issue: "Bitcoin Core MacOS - Possible Miner Infection - Bitcoin Core MacOS - Possível Infecção por Minerador"
(https://github.com/bitcoin/bitcoin/issues/31970)

💬 fanquake commented on issue "Bitcoin Core MacOS - Possible Miner Infection - Bitcoin Core MacOS - Possível Infecção por Minerador":
(https://github.com/bitcoin/bitcoin/issues/31970#issuecomment-2697012162)
Assuming you have downloaded our binaries from bitcoincore.org, this is a false-positive with your antivirus software.

⚠️ polespinasa opened an issue: "Doc: Feature deprecation and removal process documentation."
(https://github.com/bitcoin/bitcoin/issues/31980)
On https://github.com/bitcoin/bitcoin/pull/31278 we have seen that the process for deprecation and removing features is not well defined.
Would be good to have it written on the dev notes to follow always the same procedure in the future and avoid repeating the discussion.

We have different feature category, so a sub-section for each would be great.
- RPC
- Startup option
- Rest
- ZMQ
- Wallet settings
- In the future ( multiprocess interface)

💬 polespinasa commented on pull request "wallet, rpc: deprecate settxfee and paytxfee":
(https://github.com/bitcoin/bitcoin/pull/31278#discussion_r1979136930)
Left an open issue for it: https://github.com/bitcoin/bitcoin/issues/31980
I think @jonatack and @fjahr have more to say here than me.

🤔 polespinasa reviewed a pull request: "test: Use rpc_deprecated only for testing deprecation"
(https://github.com/bitcoin/bitcoin/pull/31977#pullrequestreview-2656938692)
Concept ACK.

No need to double test a functionality.

🤔 pablomartin4btc reviewed a pull request: "wallet: migration, don't create spendable wallet from a watch-only legacy wallet"
(https://github.com/bitcoin/bitcoin/pull/31423#pullrequestreview-2656958431)
Concept ACK

nit (top PR's description & last commit body - perhaps it's obvious but still):
- If the legacy wallet contains only watch-only scripts, the migration
process should only generate a watch-only **_descriptor_** wallet instead.

(I'll test and review soon)

📝 Sjors opened a pull request: "Add checkBlock() to Mining interface"
(https://github.com/bitcoin/bitcoin/pull/31981)
This PR adds the IPC equivalent of the `getblocktemplate` in `proposal` mode.

In order to do so it moves `TestBlockValidity` to `ChainstateManager` and has is return error reasons as a string instead of `BlockValidationState`. This avoids complexity in IPC code for handling the latter struct.

The new Mining interface method is used in `miner_tests` and the `getblocktemplate` and `generateblock` RPC calls, so it has test coverage.

The `inconclusive-not-best-prevblk` check is moved from R
...

✅ Sjors closed a pull request: "Add checkblock RPC and checkBlock() to Mining interface"
(https://github.com/bitcoin/bitcoin/pull/31564)

💬 Sjors commented on pull request "Add checkblock RPC and checkBlock() to Mining interface":
(https://github.com/bitcoin/bitcoin/pull/31564#issuecomment-2697113675)
I opened a fresh PR #31981 that takes only the first three commits from this one, dropping the new `checkblock` RPC as well as the reduced target verification.

Assuming most IPC / RPC consumers will use some sort of Bitcoin library to process the contents of blocks and templates, it should be easy enough for them to check the PoW.

And if I drop the `target` argument from `checkblock` it's no different from the `getblocktemplate` RPC in `proposal` mode. Which itself is easy enough to use,
...

💬 hebasto commented on pull request "ci: Test cross-built Windows executables on Windows natively":
(https://github.com/bitcoin/bitcoin/pull/31176#issuecomment-2697188523)
@davidgumberg @hodlinator @maflcko

As the CI is now green, mind taking another look?

📝 fanquake opened a pull request: "scripted-diff: rename libmultiprocess repository"
(https://github.com/bitcoin/bitcoin/pull/31982)
For when we shift `libmultiprocess` into the `bitcoin-core` organisation.