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

💬 pinheadmz commented on issue "getchaintips doesn't mark headers-only chain as invalid":
(https://github.com/bitcoin/bitcoin/issues/8050#issuecomment-1479808811)
I'm looking into this, and I've written a functional test that reproduces the issue. One thing we could do is add some extra logic into `getchaintips` itself:

- Populate `setTips`
- Iterate through `setTips` and set `status` strings
- Then we could add this here:
- If the status is `"headers-only"`, walk that branch from tip to main chain
- If an ancestor with `BLOCK_FAILED_MASK` is found, reverse walk back to tip adding `BLOCK_FAILED_CHILD` flag and inserting into `m_dirty_blockindex
...

💬 achow101 commented on pull request "wallet: Migrate non-HD keys with single combo containing a list of keys":
(https://github.com/bitcoin/bitcoin/pull/26627#issuecomment-1479842340)
> Wouldn't #20018 address most performance concerns of having a large number of `DescriptorSPKM`s? Albeit at the cost of a slightly higher memory footprint, especially in this case.

Yes, but these approaches aren't mutually exclusive, and I'd like to get feedback on both.

💬 willcl-ark commented on pull request "build: debug enable addrman consistency checks":
(https://github.com/bitcoin/bitcoin/pull/27300#issuecomment-1479890611)
@mzumsande FYI this PR is equivalent to running with `-checkaddrman=1` which does use quite some resources as it does a full addrman consistency check on pretty much every addrman operation (Add, Good, Attempt, Get, Select, Connected etc.).

For me this manifests as saturating an entire core via a combination of the `b-msghand`, `b-net` and `b-opencon` threads as these all spawn consistency checks. My `bitcoind` process usually idles at ~5%, so to have one core @ 100% is a pretty big change,
...

💬 achow101 commented on pull request "RPC: Fix fund transaction crash when at 0-value, 0-fee":
(https://github.com/bitcoin/bitcoin/pull/27271#issuecomment-1479917634)
ACK d7cc503843769b789dc5f031b4ddc75d555ba980