💬 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.

💬 MarcoFalke commented on pull request "httpserver, rest: fix segmentation fault on evhttp_uri_get_query":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1144930961)
```
test/httpserver_tests.cpp:18:12: error: constness of 'param_value' prevents automatic move [performance-no-automatic-move,-warnings-as-errors]
return param_value;
^
clang-tidy-14 --us

💬 furszy 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-1479743921)
yeah @pinheadmz, same as in the other issue. Agree on unifying all this issues into a single one. So progress updates aren't spread across the repository (I didn't even know that this existed before) and we can make reviewers calls if the sub-projects that are going toward this goal require review.

💬 pablomartin4btc commented on pull request "httpserver, rest: fix segmentation fault on evhttp_uri_get_query":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1144975901)
I'll fix this.

💬 pablomartin4btc commented on pull request "httpserver, rest: fix segmentation fault on evhttp_uri_get_query":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1144977982)
Ok, thanks.

💬 pablomartin4btc commented on pull request "httpserver, rest: fix segmentation fault on evhttp_uri_get_query":
(https://github.com/bitcoin/bitcoin/pull/27253#issuecomment-1479758216)
> 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

Yes, I have that pending to do asap.

💬 ajtowns commented on pull request "Update MANDATORY_SCRIPT_VERIFY_FLAGS":
(https://github.com/bitcoin/bitcoin/pull/26291#issuecomment-1479772800)
> wrt how the `TxValidationResult` types are used in `MaybePunishNodeForTx`, is something like this what `TX_RECENT_CONSENSUS_CHANGE` was intended for?

See #15141 where `RECENT_CONSENSUS_CHANGE` was introduced, and #11639 where it was discussed more (under the name `SOFT_FORK`). (Note that at that time, it applied to both blocks and txs, the validation results weren't separated until #15921 -- so some of the discussion there focuses more on blocks that violate recent soft fork rules rather t
...

💬 MarcoFalke commented on pull request "build: debug enable addrman consistency checks":
(https://github.com/bitcoin/bitcoin/pull/27300#issuecomment-1479775571)
Maybe there can be a `--enable-debug-symbols` (implied by `--enable-debug`) to set `-g` for the compiler?

💬 MarcoFalke 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-1479777501)
ok, closing for now as duplicate. Let us know if it isn't and if this should be reopened.

✅ MarcoFalke closed an 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)

💬 achow101 commented on pull request "wallet, tests: Expand and test when the blank wallet flag should be un/set":
(https://github.com/bitcoin/bitcoin/pull/25634#issuecomment-1479793412)
For reference, the original release note in 0.18.0 for `blank` is as follows:

> `createwallet` now has an optional `blank` argument that can be used to create a blank wallet. Blank wallets do not have any keys or HD seed. They cannot be opened in software older than 0.18. Once a blank wallet has a HD seed set (by using `sethdseed`) or private keys, scripts, addresses, and other watch only things have been imported, the wallet is no longer blank and can be opened in 0.17.x. Encrypting a blank
...