👍 TheCharlatan approved a pull request: "blocks: avoid recomputing block header hash in `ReadBlock`"
(https://github.com/bitcoin/bitcoin/pull/32487#pullrequestreview-2865691734)
ACK 8117c16fd7a0a5334fe63efaff94ea4e1d3cf851

I guess checking the hash could also protect against some weird file corruption, where a different block occupies the same position? Could this happen if e.g. the files are renamed?

💬 davidgumberg commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-2905800955)
Concept ACK

🤔 furszy reviewed a pull request: "walletdb: Log additional exception error messages for corrupted wallets"
(https://github.com/bitcoin/bitcoin/pull/32598#pullrequestreview-2865753098)
ACK ad9a13fc424e9deb262e2b1d54bcdc7370263ea0

💬 gmaxwell commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-2905866738)
Any thoughts about adding some kind of dying gasp so that if a node crashes or hits some fatal error the unfiltered log can be saved?

🤔 janb84 reviewed a pull request: "wallet, rpc: Return normalized descriptor in parent_descs"
(https://github.com/bitcoin/bitcoin/pull/32594#pullrequestreview-2865782128)
re ACK a759a22d59e805834d077a28c95695e4834983a9

Changes since last ACK:
- small typo change in commit

📝 davidgumberg opened a pull request: "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer"
(https://github.com/bitcoin/bitcoin/pull/32606)
Processing unsolicited CMPCTBLOCK's from a peer that has not been marked high bandwidth is not well-specified behavior in BIP-0152, in fact the BIP seems to imply that it is not permitted:

> "[...] method is not useful for compact blocks because `cmpctblock` blocks can be sent unsolicitedly in high-bandwidth mode"

See https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#separate-version-for-segregated-witness

This partially mitigates a mempool leak described in [#28272](#28272
...

💬 davidgumberg commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-2905911412)
Opened #32606 to drop unsolicited CMPCTBLOCK messages.

💬 davidgumberg commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2105479437)
I'll delete this on next rebase.

💬 jonatack commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-2905928927)
Concept ACK. BIP152 is marked as Final but perhaps could be clarified on this point if this moves forward.

💬 davidgumberg commented on pull request "log: print reason when writing chainstate":
(https://github.com/bitcoin/bitcoin/pull/32404#issuecomment-2905941970)
ACK https://github.com/bitcoin/bitcoin/pull/32404/commits/53e9b71b2fd59c18b75e45e3a24c39182c20a59e

💬 davidgumberg commented on pull request "log: print reason when writing chainstate":
(https://github.com/bitcoin/bitcoin/pull/32404#discussion_r2105490756)
non-blocking nit: `uint8_t` here seems unnecessary

📝 benthecarman opened a pull request: "rpc: Note in fundrawtransaction doc, fee rate is for package"
(https://github.com/bitcoin/bitcoin/pull/32607)
Accidentally made some transactions with a much higher fee rate than I wanted because I did not know this would do it for the package rather than the individual tx.

💬 davidgumberg commented on pull request "rpc: Note in fundrawtransaction doc, fee rate is for package":
(https://github.com/bitcoin/bitcoin/pull/32607#discussion_r2105492913)
```suggestion
"Only pay-to-pubkey, multisig, and P2SH versions thereof are currently supported for watch-only\n"
"Note that if specifying an exact fee rate, the resulting transaction may have a higher fee rate\n"
"if the transaction has unconfirmed inputs, this is because the wallet will attempt to make the\n"
"entire package have the given fee rate, not the resulting transaction.",
{
```

💬 roconnor-blockstream commented on pull request "refactor: Model the bech32 charlimit as an Enum":
(https://github.com/bitcoin/bitcoin/pull/30047#discussion_r2105493300)
Isn't it a bit odd to reserve `CHECKSUM_SIZE` extra bytes, when only `CreateChecksum` uses these extra bytes, but `VerifyChecksum` does not?

💬 benthecarman commented on pull request "rpc: Note in fundrawtransaction doc, fee rate is for package":
(https://github.com/bitcoin/bitcoin/pull/32607#discussion_r2105493581)
woops

💬 roconnor-blockstream commented on pull request "refactor: Model the bech32 charlimit as an Enum":
(https://github.com/bitcoin/bitcoin/pull/30047#discussion_r2105493939)
Nevermind @theuni commented about this above.

💬 gmaxwell commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-2905966115)
I wouldn't suggest bumping the HB limit at this time, as roundtripping to get transactions seems to be the long pole in the tent right now.

💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2905997778)
Couldn't find a commit error (luckily). Improved a few things on my server and now it seems to be working well:

Removed permitbaremultisig=0, datacarrier=0, increased my reduced cpu speed, give bitcoind more time before starting public electrum server Fulcrum and Core Lightning (CLN). Maybe 29.0 it a bit more demanding than 28.0. Sorry for the confusion and thanks for all the help!

✅ hMsats closed an issue: "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system"
(https://github.com/bitcoin/bitcoin/issues/32455)

💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906118037)
> > We’ve already seen a clear signal that people don’t want this, with a noticeable migration from Bitcoin Core to Bitcoin Knots over the past three weeks.
>
> It’s clear we’ve agreed to disagree: people who prefer arbitrary filters will run Bitcoin Knots, and people who prefer harmless, consensus-valid transactions will run Bitcoin Core.

Part of the motivation for this PR is that large OP RETURNs are *less* harmful than fake pub keys, with the understanding that both are still harmful.