💬 instagibbs commented on pull request "bench: Expand mempool eviction benchmarking":
(https://github.com/bitcoin/bitcoin/pull/27019#discussion_r1144872917)
Hmmm, traced out a package size of 4, looks like I'm referencing non-existent outputs, not re-using them(maybe both :) ).

Clearly this is confusing and broken either way.

To take a step back, after doing this I realized https://github.com/bitcoin/bitcoin/blob/master/src/bench/mempool_stress.cpp exists. I'm fine if this doesn't get merged if it doesn't add anything new? Helped me learn about the benchmarks if nothing else. Thoughts?

💬 glozow commented on pull request "bench: Expand mempool eviction benchmarking":
(https://github.com/bitcoin/bitcoin/pull/27019#discussion_r1144880345)
Ah true, I suppose `ComplexMemPool` is already benching eviction of packages. Fine with closing. The effort is appreciated :pray:

💬 instagibbs commented on pull request "bench: Expand mempool eviction benchmarking":
(https://github.com/bitcoin/bitcoin/pull/27019#discussion_r1144884349)
I could change the PR to remove this silly bench.. :P

✅ instagibbs closed a pull request: "bench: Expand mempool eviction benchmarking"
(https://github.com/bitcoin/bitcoin/pull/27019)

💬 stickies-v commented on pull request "httpserver, rest: fix segmentation fault on evhttp_uri_get_query":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1144885003)
Missing `#include <string>` and `#include <string_view>`

👍 stickies-v approved a pull request: "httpserver, rest: fix segmentation fault on evhttp_uri_get_query"
(https://github.com/bitcoin/bitcoin/pull/27253)
ACK 729287530e458febf32e01e542a36e7be4a74fbf

Also checked that the new functional test fails without the patch and succeeds with the patch.

but I think the commit message [should be updated](https://github.com/bitcoin/bitcoin/pull/27253#pullrequestreview-1348929370) to better describe the bug, the fix, and the behaviour change introduced

💬 instagibbs commented on pull request "RPC: Fix fund transaction crash when at 0-value, 0-fee":
(https://github.com/bitcoin/bitcoin/pull/27271#issuecomment-1479651136)
@furszy is that an ACK? :)

💬 hebasto commented on pull request "refactor: Make `CCheckQueue` RAII-styled":
(https://github.com/bitcoin/bitcoin/pull/26762#issuecomment-1479655825)
Updated 5a7932f395c675fad332cbcd0498bb9fefcb33e0 -> f1370b2c1586f7fe487d9f17ee53bcd9b87a9f23 ([pr26762.04](https://github.com/hebasto/bitcoin/commits/pr26762.04) -> [pr26762.05](https://github.com/hebasto/bitcoin/commits/pr26762.05)):

- rebased
- addressed some of @TheCharlatan's comments

💬 pinheadmz commented on issue "Use of a wallet shouldn't be blocked in prune mode ("wallet loading failed... beyond pruned data")":
(https://github.com/bitcoin/bitcoin/issues/27188#issuecomment-1479656461)
> @willcl-ark That still won't work when the pruning point is later than the wallet birth date.

What if it is combined with `getblockfrompeer` logic?

I think we could close this issue in favor of https://github.com/bitcoin/bitcoin/issues/21267 and with the goal of essentially adding neutrino functionality to a pruning node for the sake of wallet rescans and imports ?

💬 hebasto commented on pull request "refactor: Make `CCheckQueue` RAII-styled":
(https://github.com/bitcoin/bitcoin/pull/26762#discussion_r1144896704)
Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/26762#issuecomment-1479655825).

💬 MarcoFalke commented on pull request "ci: Use TSan new runtime (llvm-16, take 3)":
(https://github.com/bitcoin/bitcoin/pull/27298#issuecomment-1479657784)
> Could we drop the GUI from the TSan task?

Yes, but there is another (linker) bug.

💬 prusnak commented on pull request "Add feerate histogram to getmempoolinfo":
(https://github.com/bitcoin/bitcoin/pull/21422#issuecomment-1479660108)
@sipa By not providing sort-of accurate estimations from the current mempool, we force people to rely on third-party estimators, which is arguably much worse than having an independent estimation which works most of the time, although it may be games under certain specific conditions. I think that "perfect is enemy of good" rule applies here perfectly.

💬 hebasto commented on pull request "refactor: Make `CCheckQueue` RAII-styled":
(https://github.com/bitcoin/bitcoin/pull/26762#discussion_r1144903304)
> This is not consistent with how the other options are handled. This overrides the value of the passed in option even if no argument was passed in. I would handle this the same way as `max_tip_age`...

I'm not sure about this change considering this PR scope. The semantic of the "-par" and "-maxtipage" options are quite different.

> ... and also move the `MAX_SCRIPTCHECK_THREADS` to `chainstatemanager_opts.h`.

Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/26762#issuecomment-
...

💬 pinheadmz commented on issue "pruneblockchain should be able to increase the size of pruned blockchain":
(https://github.com/bitcoin/bitcoin/issues/24286#issuecomment-1479666190)
I think both this issue and https://github.com/bitcoin/bitcoin/issues/19807 can be closed simply because after we erase undo data, there is no way to recover it without re-syncing from genesis.

If a user wants to keep more data on disk like @carnhofdaki said, you can increase the `-prune` value and wait for it to fill up with new blocks.

If a user just wants pre-prune block data for wallet rescans, I think using neutrino filters and `getblockfrompeer` would be a cool feature, see https://g
...

💬 pinheadmz commented on issue "Manual-pruning cursor rewind":
(https://github.com/bitcoin/bitcoin/issues/19807#issuecomment-1479668791)
See https://github.com/bitcoin/bitcoin/issues/24286#issuecomment-1479666190 I think these two issues can be closed and a feature we could work on is a neutrino mode for a wallet attached to a pruning node... ?

💬 furszy commented on issue "Allow for rescan using block filters with pruned node":
(https://github.com/bitcoin/bitcoin/issues/21267#issuecomment-1479678755)
Yeah @darosior, thanks for the ping. Let's update this issue.

I do have a running version of this. And the complete project extends beyond this use case actually.

As is often the case, the working path hasn't been as straight as expected. I have been improving orthogonal components in parallel to make the end result cleaner and more usable. For example, to make the mainnet live tests less painful, have created #26966 to reduce the time it takes for the block filter index to sync from ~7 ho
...

💬 LarryRuane commented on pull request "Add pool based memory resource":
(https://github.com/bitcoin/bitcoin/pull/25325#issuecomment-1479679004)
ACK d87cb99bb37637e26a9e00b9f7de4bc6f44cb79d

💬 furszy commented on issue "Manual-pruning cursor rewind":
(https://github.com/bitcoin/bitcoin/issues/19807#issuecomment-1479682702)
> See [#24286 (comment)](https://github.com/bitcoin/bitcoin/issues/24286#issuecomment-1479666190) I think these two issues can be closed and a feature we could work on is a neutrino mode for a wallet attached to a pruning node... ?

yeah, I have been working on it. Just answered in https://github.com/bitcoin/bitcoin/issues/21267. Got sidetracked with some other useful features to make mainnet tests less painful.

💬 glozow commented on pull request "Update MANDATORY_SCRIPT_VERIFY_FLAGS":
(https://github.com/bitcoin/bitcoin/pull/26291#issuecomment-1479684455)
Concept ACK to at least not reporting consensus script failures as "non-mandatory."

wrt how the `TxValidationResult` types are used in `MaybePunishNodeForTx`, is something like this what `TX_RECENT_CONSENSUS_CHANGE` was intended for?

💬 furszy commented on issue "pruneblockchain should be able to increase the size of pruned blockchain":
(https://github.com/bitcoin/bitcoin/issues/24286#issuecomment-1479690163)
> If a user just wants pre-prune block data for wallet rescans, I think using neutrino filters and getblockfrompeer would be a cool feature, see https://github.com/bitcoin/bitcoin/issues/21267

yeah, I would say to unify all this issues into a single one. So I can send progress updates and make reviewers calls if the sub-projects require review.