✅ achow101 closed an issue: "implicit-integer-sign-change in ActivateSnapshot"
(https://github.com/bitcoin/bitcoin/issues/30514)

🚀 achow101 merged a pull request: "assumeutxo: Drop block height from metadata"
(https://github.com/bitcoin/bitcoin/pull/30598)

💬 achow101 commented on pull request "contrib/signet/miner updates":
(https://github.com/bitcoin/bitcoin/pull/28417#issuecomment-2278716451)
ACK fb6d51eb25a2bb69a3ecdfc4796a88d4d1aacc65

💬 sipa commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2278726067)
It would be good to know what impact it has on IBD, as it's necessarily going to make things slower (more syncs means more disk writes, and more memory/cpu to remember UTXOs which must be marked spent on disk), for the benefit of reducing losses in case of crashes. The question is how much time & I/O it adds.

Regarding doing it for every block (during steady state), the trade-off there is different. On the pro side there is a reduction of latency spikes instead of reducing crash losses (as th
...

💬 maflcko commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2278758371)
Did you get a chance to see if you can reproduce the crash, if you put all data and swap on a single root SSD?

💬 achow101 commented on pull request "p2p: For assumeutxo, download snapshot chain before background chain":
(https://github.com/bitcoin/bitcoin/pull/29519#issuecomment-2278782453)
ACK 49d569cb1fdd62a9da8dff51dccaf4680fe3d0eb

🚀 achow101 merged a pull request: "p2p: For assumeutxo, download snapshot chain before background chain"
(https://github.com/bitcoin/bitcoin/pull/29519)

💬 andrewtoth commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2278793149)
> It would be good to know what impact it has on IBD, as it's necessarily going to make things slower

Note that it is only necessarily slower when running with very high dbcache settings. For default settings the cache fills up and is flushed far more often than every hour, so this will have no effect.

💬 tdb3 commented on pull request "fix: increase consistency of rpcauth parsing":
(https://github.com/bitcoin/bitcoin/pull/30401#issuecomment-2278800814)
Rebased. Addressed comments from @naiyoma and @ryanofsky.

💬 tdb3 commented on pull request "fix: increase consistency of rpcauth parsing":
(https://github.com/bitcoin/bitcoin/pull/30401#discussion_r1712258890)
Added log statements. Thanks.

💬 tdb3 commented on pull request "fix: increase consistency of rpcauth parsing":
(https://github.com/bitcoin/bitcoin/pull/30401#discussion_r1712261127)
Thanks. Dropped the four lines so the errors are handled together. Reordered the commits so the tests are first, then the fix. The tests were adjusted to prevent "test each commit" from failing.

🤔 furszy reviewed a pull request: "wallet: Fix listwalletdir listing of migrated default wallets and generated backup files"
(https://github.com/bitcoin/bitcoin/pull/30265#pullrequestreview-2231114653)
Code ACK 6b2dcba076

📝 furszy opened a pull request: "wallet: fix blank legacy detection"
(https://github.com/bitcoin/bitcoin/pull/30621)
Blank legacy wallets do not have active SPKM. They can only be
detected by checking the descriptors' flag or the db format.

This enables the migration of blank legacy wallets in the GUI.

To test this:
1) Create a blank legacy wallet.
2) Try to migrate it using the GUI's toolbar "Migrate Wallet" button.
-> In master: The button will be disabled because `CWallet::IsLegacy()` returns false for blank legacy wallet.
-> In this PR: the button will be enabled and allow the legacy wa
...

⚠️ Sheryl17 opened an issue: "Disclosure of remote crash due to addr message spam

Nodes could be spammed with addr messsages, which could be used to crash them. A fix was released on September 14th, 2021 in Bitcoin Core v22.0.

"
(https://github.com/bitcoin/bitcoin/issues/30622)

✅ achow101 closed an issue: "Disclosure of remote crash due to addr message spam

Nodes could be spammed with addr messsages, which could be used to crash them. A fix was released on September 14th, 2021 in Bitcoin Core v22.0.

"
(https://github.com/bitcoin/bitcoin/issues/30622)

:lock: achow101 locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/30622)

🤔 stickies-v reviewed a pull request: "node: reduce unsafe uint256S usage"
(https://github.com/bitcoin/bitcoin/pull/30569#pullrequestreview-2231282040)
> Why not allow 0x prefixes as -minimumchainwork does?

Because my understanding is that `0x` is used for hex numbers, and a block hash is not a number. So we have to make a trade-off between not introducing "weirdness" into the code vs maintaining backwards compatibility (for an undocumented feature). I prefer leaning towards the former unless there are good reasons to go for the latter, but that's exactly the reason I carved out these commits into a smaller commit so thank you for your inpu
...

💬 stickies-v commented on pull request "node: reduce unsafe uint256S usage":
(https://github.com/bitcoin/bitcoin/pull/30569#discussion_r1712441877)
> Would be good to change "Size of" to "Desired size of".

"Desired" to me sounds like the result string may not actually be of the requested size, when it is actually guaranteed. I'm not sure that would be an improvement?

💬 stickies-v commented on pull request "node: reduce unsafe uint256S usage":
(https://github.com/bitcoin/bitcoin/pull/30569#discussion_r1712444215)
> I think instead of saying this "sanitizes" the string and pretending like that word means something it would be better to just say this strips 0x prefixes and fixes the length of the string so it can be passed to the base_blob::ParseHex() function.

Yeah, I felt a bit uneasy about the arbitrariness of what the function is doing and how it's named. I can't really come up with a better name, though, but I'm open to suggestions?

An alternative would be to, as @maflcko initially [suggested](h
...

💬 stickies-v commented on pull request "node: reduce unsafe uint256S usage":
(https://github.com/bitcoin/bitcoin/pull/30569#discussion_r1712438144)
> I don't think this should be a standalone function when it is only called one place.

The reason I organized it this way is because I was quite surprised to see that we don't have unit testing on setting options from arguments, and `SetOptsFromArgs()` can trivially (when templated) be reused for any other options setting test, avoiding (non-move) changes to this file. With that said, would you still prefer not having a separate function, or e.g. templating it (prematurely) and moving it into
...