💬 janb84 commented on issue "Guix: build riscv64 master / v30rc1 fails":
(https://github.com/bitcoin/bitcoin/issues/33426#issuecomment-3307226772)
> > Added console log, and build logs
> > [console.log](https://github.com/user-attachments/files/22406285/console.log)
>
> Does it include stderr output as well?
Unfortunately not, just piped the output to a file. Working on it :)

💬 brunoerg commented on issue "coin-grinder missing test for TOTAL_TRIES":
(https://github.com/bitcoin/bitcoin/issues/33419#issuecomment-3307249900)
For reference: https://corecheck.dev/mutation/src/wallet/coinselection.cpp (L466 and L468)

💬 hebasto commented on issue "build: secp256k1 warnings not turned into errors in MSAN job":
(https://github.com/bitcoin/bitcoin/issues/33284#issuecomment-3307302109)
Related: https://github.com/bitcoin-core/secp256k1/pull/1750.

💬 fanquake commented on issue "Linux download needs installation instructions":
(https://github.com/bitcoin/bitcoin/issues/32097#issuecomment-3307307680)
@hebasto can you followup here

💬 fjahr commented on pull request "wallet/rpc: add scan_utxoset option to getbalance(s) to verify wallet balance accuracy":
(https://github.com/bitcoin/bitcoin/pull/33392#issuecomment-3307315975)
> Just to make sure we’re on the same page — my understanding is that the idea is to:
>
> Use chunked backward rescans starting from the supplied birthdate (e.g. 1000-block increments), and stop as soon as the wallet balance matches the UTXO-set scan. This handles the common case where the birthdate is only off by a few days or weeks, so we don’t need to rescan the entire chain.

Right, so for example if the supplied birthdate was blockheight `800,000` but there is a discrepancy, then, inst
...

💬 fanquake commented on pull request "Update libmultiprocess subtree to fix intermittent mptest hang":
(https://github.com/bitcoin/bitcoin/pull/33412#issuecomment-3307342620)
cc @Sjors

💬 fanquake commented on pull request "ci: run native_fuzz_with_msan":
(https://github.com/bitcoin/bitcoin/pull/33425#issuecomment-3307360138)
Runtime is alright, and similar to Valgrind, is being blown a bit by the slowest tests. i.e mini_miner running for a half hour:
```bash
Run mini_miner with args ['/home/admin/actions-runner/_work/_temp/build/bin/fuzz', '-runs=1', PosixPath('/home/admin/actions-runner/_work/_temp/ci/scratch/qa-assets/fuzz_corpora/mini_miner')]INFO: Running with entropic power schedule (0xFF, 100).
<snip>
Done 641 runs in 1868 second(s)
Run txdownloadman_impl with args ['/home/admin/actions-runner/_work/_temp
...

💬 fanquake commented on issue "fuzz: Speed up mini_miner fuzz target?":
(https://github.com/bitcoin/bitcoin/issues/32870#issuecomment-3307388406)
No, this is still an issue. See here: https://github.com/bitcoin/bitcoin/pull/33425#issuecomment-3307360138. `mini_miner` is running for ~half an hour. cc @murchandamus @glozow

📝 john-moffett opened a pull request: "rpc: Always return per-wtxid entries in submitpackage tx-results"
(https://github.com/bitcoin/bitcoin/pull/33427)
Follow-up to #28848

When `submitpackage` produced no per-transaction result for a member, the RPC set `"error": "unevaluated"` but then continued without inserting the entry into `tx-results`, making it impossible for callers to know which `wtxids` were unevaluated.

This inserts the error result before continuing, updates help text, and adjusts functional tests to expect entries for all submitted `wtxids`.

🤔 glozow reviewed a pull request: "rpc: Always return per-wtxid entries in submitpackage tx-results"
(https://github.com/bitcoin/bitcoin/pull/33427#pullrequestreview-3239717920)
Concept ACK, this looks like an unintentional drop. I thought "unknown-not-validated" would be better since it matches the error string for skipped transactions, but I think it's better to have separate messages for "nothing was validated because the package was ill-formed" vs "this particular transaction wasn't validated."

cc @instagibbs

💬 janb84 commented on issue "Guix: build riscv64 master / v30rc1 fails":
(https://github.com/bitcoin/bitcoin/issues/33426#issuecomment-3307456826)
Going to close this issue, it was a memory exhaustion problem.

Seems like V30 needs just a little more memory to build than V29.x

```console
collect2: fatal error: ld terminated with signal 9 [Killed]
compilation terminated.
make[2]: *** [src/qt/CMakeFiles/bitcoin-gui.dir/build.make:201: bin/bitcoin-gui] Error 1
make[2]: *** Deleting file 'bin/bitcoin-gui'
make[1]: *** [CMakeFiles/Makefile2:1991: src/qt/CMakeFiles/bitcoin-gui.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
```

...

✅ janb84 closed an issue: "Guix: build riscv64 master / v30rc1 fails"
(https://github.com/bitcoin/bitcoin/issues/33426)

💬 instagibbs commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#issuecomment-3307462465)
concept ACK

💬 sdaftuar commented on pull request "Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2359339020)
Looks like this was me just flubbing with the conversion of `GetCountWithAncestors()` to `GetNumDescendants()` instead of `GetNumAncestors()`? I'll just make that switch for now, rather than try to re-write this code using `GetCluster()`, which I'd rather save for a future PR at this point.

I also don't want to introduce a behavior change here, but as an aside I was surprised that no test failed with this mistake, and when looking at the original PR to refresh my memory I found this comment
...

💬 glozow commented on issue "fuzz: Speed up mini_miner fuzz target?":
(https://github.com/bitcoin/bitcoin/issues/32870#issuecomment-3307495980)
Unsure what the best course of action is, since the plan is to reimplement MiniMiner anyway after #28676. If there's a timeout/infinite loop then that's a bug we should fix for current wallet users. But if it's just a slow test, then I'd suggest leaving it as is and it will probably fix itself when mempool is more efficient at cluster calculation.

I haven't looked into the input itself (idk if @enirox001 or somebody wants to do it) but if the culprit is just too many potential outpoints then we
...

💬 instagibbs commented on pull request "Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2359350996)
didnt you nuke GetNumAncestors?

💬 Eunovo commented on pull request "Silent Payments: Receiving":
(https://github.com/bitcoin/bitcoin/pull/32966#issuecomment-3307502671)
> It would be nicer if it just toggled the flag; I don't think anyone would accidentally perform such an import - and the flag is immutable via `setwalletflag`.

@Sjors Did you mean the flag is "mutable" via `setwalletflag`?

I don't have anything against automatically toggling silent-payments flag when a silent payment descriptor is imported.
@josibake WDYT?

💬 sipa commented on pull request "p2p: Increase tx relay rate":
(https://github.com/bitcoin/bitcoin/pull/28592#issuecomment-3307523145)
ACK b81f37031c8f2ccad9346f1b65ee0f8083c44796

💬 fanquake commented on pull request "p2p: Increase tx relay rate":
(https://github.com/bitcoin/bitcoin/pull/27630#issuecomment-3307535613)
Followed up in #28592.

💬 Sjors commented on pull request "Silent Payments: Receiving":
(https://github.com/bitcoin/bitcoin/pull/32966#issuecomment-3307550172)
@Eunovo when I call `setwalletflag` it fails, saying the flag is immutable. I'm fine with either solution:
1. Make it mutable; or
2. Set it when importing an sp descriptor