💬 Crypt-iQ commented on pull request "log: reduce excessive "rolling forward" messages during block replay":
(https://github.com/bitcoin/bitcoin/pull/33443#discussion_r2369079142)
A new macro was not introduced in the original PR / was an intentional change so that a developer would have to use the "private" macro `LogPrintLevel_` with `should_ratelimit=false` in order to bypass rate limiting. This change is fine code-wise, but my concern is that it's now easier for a developer to accidentally introduce a logging location that an attacker can trigger. Maybe the comment for the macro can be modified to "Same as LogInfo, but never rate limited. Should be used with extreme c
...

💬 mzumsande commented on pull request "validation: Make ReplayBlocks interruptible":
(https://github.com/bitcoin/bitcoin/pull/30155#issuecomment-3319820076)
> Needs a rebase, but otherwise Concept ACK

Rebased for fresh CI (rebase seemed clean, didn't change anything)

💬 monlovesmango commented on issue "30.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/33369#issuecomment-3319820537)
I am running Arch Linux x86_64. Please let me know if there is anything I can do to help diagnose this issue.

💬 andrewtoth commented on pull request "net: support overriding the proxy selection in ConnectNode()":
(https://github.com/bitcoin/bitcoin/pull/33454#issuecomment-3319833946)
Need to update https://github.com/bitcoin/bitcoin/pull/33454/files#diff-00021eed586a482abdb09d6cdada1d90115abe988a91421851960e26658bed02L2882 `strDest` -> `pszDest` to placate tidy.

🚀 hebasto merged a pull request: "system: improve handling around GetTotalRAM()"
(https://github.com/bitcoin/bitcoin/pull/33435)

💬 ryanofsky commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#discussion_r2369187858)
re: https://github.com/bitcoin/bitcoin/pull/33374#discussion_r2365640546

> This test only calls `submitSolution()` once, unless I'm missing something?

Sorry I just misread the diff, didn't notice the first call was being deleted

💬 monlovesmango commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3319935660)
I was doing some extra adhoc testing for section 7.1 in the testing guide and hoping for guidance on whether the result is expected or not. If I create a tx3 that is a child of tx2 (all as v3 txs) the `send` command fails silently. It failing is the correct behavior because the package size shouldn't be greater than 2, but was unsure if the fail should be silent? Below will create the 3 truc transactions and check if tx3 is in mempool.

```bash
TRUC_address=$(bcli30 getnewaddress)
tx=$(bcli30 -n
...

💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3319941069)
My Guix build:
```
aarch64
01ad8136b264db6408b4eaec324a8950aa1ba5096f0bad9e2bd5dcb21cf4ef30 guix-build-3e69b6973607/output/aarch64-linux-gnu/SHA256SUMS.part
7a6abbd1721b008f05358acee75662bc76028cb65da8bbc2435ccc258429b064 guix-build-3e69b6973607/output/aarch64-linux-gnu/bitcoin-3e69b6973607-aarch64-linux-gnu-debug.tar.gz
a88021c9867d1859784195354d2a79d400b0b24be9baa06968236dffccf0bb71 guix-build-3e69b6973607/output/aarch64-linux-gnu/bitcoin-3e69b6973607-aarch64-linux-gnu.tar.gz
0ece5435
...

💬 Kruwed commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3319944425)
>**Many current Bitcoin Core users want to continue using this option**
This statement is based on public postings from many Bitcoin Core users and not a formal survey.

Popularity is not a sufficient reason alone, can you provide any of the underlying reasons why these users want to continue using this option?

💬 waketraindev commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3320038208)
Concept ACK

💬 adam3us commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3320053572)
> While I agree with the logic for un-deprecation, I don't think this PR goes far enough as the functionality of the datacarriersize argument is fundamentally different than what it was in v29. Multiple OP_RETURN outputs are still allowed by this change, creating a situation where users cannot get the same behavior from their nodes' relay policy from previous versions through configuration.
>
> It's still a mystery to me why multiple OP_RETURNs are being allowed since an extra OP_RETURN costs
...

👍 jonatack approved a pull request: "docs: Undeprecate datacarrier and datacarriersize configuration options"
(https://github.com/bitcoin/bitcoin/pull/33453#pullrequestreview-3253916968)
ACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Agree with the change, reviewed, verified that it is clean revert of 0b4048c73385166144d0b, built/ran tests locally.

💬 jonatack commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3320067548)
Note: the translation files would need updating?

💬 bitschmidty commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3320079835)
> Popularity is not a sufficient reason alone, can you provide any of the underlying reasons why these users want to continue using this option?

Sure, from what Ive seen: Some miners want to use Bitcoin Core for block template building but dont want to include large op_returns. Relay nodes/node runners do not want to relay unconfirmed large op_returns.

🤔 Zero-1729 reviewed a pull request: "docs: Undeprecate datacarrier and datacarriersize configuration options"
(https://github.com/bitcoin/bitcoin/pull/33453#pullrequestreview-3253975016)
crACK 451ba9ada41f687c0e4bb34d5925374a68a8f8a3

Agree with the rationale in the OP. This is a step in the right direction IMHO.

💬 Kruwed commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3320173852)
>Sure, from what Ive seen: Some miners want to use Bitcoin Core for block template building but don't want to include large op_returns. Relay nodes/node runners do not want to relay unconfirmed large op_returns.

Why should Bitcoin Core support a config option to perform targeted censorship of large OP_RETURNs?

🤔 ismaelsadeeq reviewed a pull request: "rpc: fix getblock(header) returns target for tip"
(https://github.com/bitcoin/bitcoin/pull/33446#pullrequestreview-3254118873)
Concept ACK

⚠️ ArmchairCryptologist opened an issue: "Documentation trap when using -bind in conjunction with (automatically configured) Tor hidden services"
(https://github.com/bitcoin/bitcoin/issues/33458)
To start with the conclusion: everything appears to work as _intended_, so this should probably not be considered a bug as such, but some logging and telemetry output could be improved to make things clearer.

If you use -bind to manually specify which (public) IPs to listen to, Bitcoin Core will also no longer create the (local) default socket for incoming Tor connections at 127.0.01:8334 unless you specify it manually in your list - this is probably working as intended. When automatically crea
...

💬 mzumsande commented on pull request "wallet: reduce unconditional logging during load":
(https://github.com/bitcoin/bitcoin/pull/33299#discussion_r2369524532)
thanks - I took that.

💬 mzumsande commented on pull request "wallet: reduce unconditional logging during load":
(https://github.com/bitcoin/bitcoin/pull/33299#issuecomment-3320316739)
> This version doesn't work properly and produces the same issue it's trying to fix

Good catch, must have missed this during testsing! Changed to your suggestion with a `static`.