📝 musaHaruna opened a pull request: "rpc: add scan_utxoset option to getbalance(s) to verify wallet balance accuracy"
(https://github.com/bitcoin/bitcoin/pull/33392)
Fixes [#28898](https://github.com/bitcoin/bitcoin/issues/28898)
Users who import descriptors with incorrect birthdates may encounter inaccurate wallet balances. In such cases, the wallet may miss historical transactions that belong to it, resulting in underreported balances.
Currently, the only way to correct this is to manually run rescanblockchain or reimport descriptors with proper metadata. However, users may not realize that their wallet balance is incomplete.
This PR introduces a mechan
...

💬 Sjors commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#discussion_r2349501608)
> But one thought is that maybe serializing whole block is not necessary, and this could just return `CBlockHeader`?

I think it's easier to use if we just return the block. Otherwise a client has the call `getBlock()`, then `applySolution()` and then swap out the header in the block they got. In which case they might as well just apply the solution themselves.

I think the two main use cases for this are:
1. Testing mining (pool) software, which doesn't need to be performant
2. Debugging
...

💬 D33r-Gee commented on pull request "Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications":
(https://github.com/bitcoin/bitcoin/pull/33117#issuecomment-3293023636)
With [30d9bdb](https://github.com/bitcoin/bitcoin/commit/30d9bdb77324d234d4aacd155075b4dfc00930c7), the `loadtxoutset` RPC command has been refactored to use the snapshot interface, as suggested by @Sjors. Additionally, the interface now includes `getMetadata` and `getActivationResult` methods to ensure parity with the legacy RPC command.

💬 D33r-Gee commented on pull request "Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications":
(https://github.com/bitcoin/bitcoin/pull/33117#discussion_r2349555648)
> a good way to add test coverage to this

refactored `loadtxoutset` to utilize the new `snapshot` interface...

⚠️ Rev-9T opened an issue: "v30 Testing (BUG)"
(https://github.com/bitcoin/bitcoin/issues/33393)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

1. It has a very serious vulnerability by defaulting op_return to 100,00 bytes.
2. No op_return customisation options.

### Expected behaviour

op_return should be no more than 42 bytes.

### Steps to reproduce

Updated the `bitcoin.conf` file
Added `datacarriersize=42`

### Relevant log output

_No response_

### How did you obtain Bitcoin Core

Compiled from source

### What version of
...

💬 polespinasa commented on pull request "rpc, logging: add backgroundvalidation to getblockchaininfo":
(https://github.com/bitcoin/bitcoin/pull/33259#discussion_r2349650823)
thanks 👍

💬 polespinasa commented on pull request "rpc, logging: add backgroundvalidation to getblockchaininfo":
(https://github.com/bitcoin/bitcoin/pull/33259#discussion_r2349653359)
I don't think that's useful. The test is not much longer than others and `check_tx_counts` is separated in a function because it's called multiple times with different values of `final`. In this case there's no duplicated code.

💬 polespinasa commented on pull request "rpc, logging: add backgroundvalidation to getblockchaininfo":
(https://github.com/bitcoin/bitcoin/pull/33259#issuecomment-3293196760)
21fb4c949cebf3510dad3dc3827ccb9451e4828d correct typos

💬 ryanofsky commented on pull request "test: don't throw from the destructor of DebugLogHelper":
(https://github.com/bitcoin/bitcoin/pull/33388#issuecomment-3293213987)
Cap'n Proto has a policy of declaring destructors `noexcept(false)` and using `std::uncaught_exception()` to prevent throwing more than once under the assumption that "ff another exception is already active, the new exception is assumed to be a side-effect of the main exception, and is either silently swallowed or reported on a side channel." It seems like that could be a reasonable approach here. The DebugLogHelper destructor could continue to throw normally, but just log if another exception w
...

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349670936)
I tried explaining it in
[`6222d8c` (#33336)](https://github.com/bitcoin/bitcoin/pull/33336/commits/6222d8cced4828b83a9dde20b9da9df44848b9bd)
> Instead of true/false or enabled/disabled, the checked/skipped naming should help with understanding when signature verification is actually performed.

But seems it's not a good explanation. I found it confusing to say that we disable assume valid - so are we doing the script checks or not. So what's a better expression to avoid the confusion?

💬 Roasbeef commented on issue "Difficulty in reliably mapping errors from Bitcoin Core due to unstable error codes and messages":
(https://github.com/bitcoin/bitcoin/issues/33350#issuecomment-3293222771)
Ah, I meant `testmempoolaccept`. `testmempoolaccept` was called, but a new/different error was returned, so we weren't able to make a decisions w.r.t "should we retry or is it hosed".

Re atomic transaction submission, what I mean is that a sort of race condition can arise between the time you call `testmempoolaccept`, and when you actually submit the package.

✅ achow101 closed an issue: "v30 Testing (BUG)"
(https://github.com/bitcoin/bitcoin/issues/33393)

🤔 l0rinc reviewed a pull request: "log: always print initial signature verification state"
(https://github.com/bitcoin/bitcoin/pull/33336#pullrequestreview-3225673910)
Thanks for the suggestions, applied most of them

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349705964)
But extracting `TWO_WEEKS_IN_SECONDS` is safe, did that, thanks. Added you as coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349700463)
Done

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349699960)
Changed in latest push, thanks

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349714482)
Lol, valid point, let's document what we *are* doing, not just what we're not :D
Added comment and updated the commit message (but kept the todo for now), added you as coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349709237)
the 4th is doing a reindex even in the first commit, right?

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349696433)
Done, thanks, added you as coauthor

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349727088)
Done