💬 ryanofsky commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1187459164)
In commit "refactor: Move functions to BlockManager methods" (1def580e80a1892e473324016db9a0f2ffec0c27)

re: https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1140490220

> Thank you for the suggestion, will split this up.

Seems like this could be marked resolved

💬 ryanofsky commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1187472027)
In commit "refactor: Use BlockManager options for params" (0400fb7b55415867d9ff0aa88898920c60b4b2df)

Seem like you could squash this commit into the last commit and decrease review burden because the changes are mechanical and basically every line that changed here changed last commit. Not important though.

💬 Sjors commented on pull request "Switch hardened derivation marker to h":
(https://github.com/bitcoin/bitcoin/pull/26076#discussion_r1187491311)
Descriptors have always required parsers to handle both `h` and `'`, and I'm not aware of any that don't. For old BIP32 derivation parsing software I'm less sure about that.

💬 Sjors commented on pull request "Switch hardened derivation marker to h":
(https://github.com/bitcoin/bitcoin/pull/26076#issuecomment-1538425147)
Thanks for the review!

The reason for not breaking legacy wallet RPC calls is that I'm assuming any code that uses legacy wallets is really old and nobody wants to touch it. On our side eventually we want to get rid of the legacy wallet - or at least freeze it - so there's no need to modernise it.

I updated the title, description and release note. Pushed the latter as a new commit to not lose ACKs.

💬 Sjors commented on pull request "Switch hardened derivation marker to h":
(https://github.com/bitcoin/bitcoin/pull/26076#discussion_r1187496219)
Added (plus "and similar")

🤔 darosior reviewed a pull request: "Switch hardened derivation marker to h"
(https://github.com/bitcoin/bitcoin/pull/26076#pullrequestreview-1416887139)
re-ACK fe49f06c0e91b96feb8d8f1bd478c3173f14782c

💬 Sjors commented on pull request "Remove Taproot activation height":
(https://github.com/bitcoin/bitcoin/pull/26201#issuecomment-1538431662)
I'll rebase soon(tm).

🚀 fanquake merged a pull request: "msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0"
(https://github.com/bitcoin/bitcoin/pull/27580)

💬 pinheadmz commented on pull request "msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0":
(https://github.com/bitcoin/bitcoin/pull/27580#issuecomment-1538433259)
ACK
I noticed when switching locally between old and new branches that some untracked files got left over:

```

--> git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
(use "git add <file>..." to include in what will be committed)
src/secp256k1/src/libsecp256k1-config.h
src/secp256k1/src/libsecp256k1-config.h.in
src/secp256k1/src/stamp-h1

nothing added to commit but untracked files present (use "git add" to track)
```

💬 pinheadmz commented on pull request "msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0":
(https://github.com/bitcoin/bitcoin/pull/27580#issuecomment-1538447056)
Actually I still get the untracked files warning after merge -- am i doing something wrong? Or would it make any sense to add these to gitignore?

💬 Sjors commented on pull request "rpc: distinguish between vsize and sigop-adjusted mempool vsize":
(https://github.com/bitcoin/bitcoin/pull/27591#issuecomment-1538451521)
Concept ACK on clarifying and returning both variants.

It would useful to peruse a few other projects to see how they use `getmempoolentry` and `getrawmempool`, to determine if this is a breaking change.

👍 ryanofsky approved a pull request: "refactor: Move chain constants to the util library"
(https://github.com/bitcoin/bitcoin/pull/27491#pullrequestreview-1416874927)
Code review ACK 95744f9cf1f143b6449a5046a914557b3886e3a2.

I think this looks good in it's current form, but the PR would have less churn and be simpler overall if the last commit "refactor: Avoid needless chain type string conversions" (95744f9cf1f143b6449a5046a914557b3886e3a2) was done earlier and became the second commit before commit "refactor: Replace string chain name constants with ChainTypes" (ca13faf0cc8acbaf425ac69c783415465403b5a3)

💬 ryanofsky commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1187490948)
In commit "refactor: Replace string chain name constants with ChainTypes" (ca13faf0cc8acbaf425ac69c783415465403b5a3)

Could this new method be added in an earlier commit? This commit is very long and all the other changes in the commit are mechanical changes except this one method, so the new code seems to get lost.

(This would also open the door to automating the other changes in this commit with a scripted-diff, though that would still be awkward not and not necessary IMO)

💬 ryanofsky commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1187504635)
In commit "refactor: Avoid needless chain type string conversions" (95744f9cf1f143b6449a5046a914557b3886e3a2)

Would be helpful to have a code comment describing what this does. Like "Return -regtest/-signet/-testnet/-chain= setting as a ChainType enum if a recognized chain name was set, or as a string if an unrecognized chain name was set. Raise an exception if an invalid combination of flags was provided.

💬 ryanofsky commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1187514090)
In commit "refactor: Avoid needless chain type string conversions" (95744f9cf1f143b6449a5046a914557b3886e3a2)

It seems like this commit could be moved before the "refactor: Replace string chain name constants with ChainTypes" (ca13faf0cc8acbaf425ac69c783415465403b5a3)" commit, which would simplify that commit, and avoid for the `ArgsManager::GetChainType()` method to change after it is added. I think the only change you would need to make to the code in this commit to move it earlier would be
...

💬 fanquake commented on pull request "fuzz: improve `coinselection`":
(https://github.com/bitcoin/bitcoin/pull/27585#issuecomment-1538483661)
cc @achow101 @Xekyo @furszy

⚠️ fanquake opened an issue: "ci: failure in feature_taproot.py (TSAN)"
(https://github.com/bitcoin/bitcoin/issues/27595)
master at 26cb32c02d76d6635c67942a5eeb70a6199df69d. https://cirrus-ci.com/task/5769539133112320?logs=ci#L3369:
```bash
node0 2023-05-08T14:19:47.988934Z [httpworker.1] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=sendrawtransaction user=__cookie__
test 2023-05-08T14:19:47.989000Z TestFramework (ERROR): JSONRPC error
Traceback (most recent call last):
File "/tmp/cirrus-ci-build/ci/scratch/build/bitcoin
...

💬 instagibbs commented on issue "Avoid serving stale fees":
(https://github.com/bitcoin/bitcoin/issues/27555#issuecomment-1538504504)
Here's my guess on how this happens and explaining the behavior I'm seeing
1) On node restart, there is no persistence of mempoolminfee
2) While mempool is importing, node receives transactions well below the old mempoolminfee, enters into mempool
3) mempool finishes loading(with some failures), resulting in no trimming on startup
4) `mempoolminfee` seems to be feeding into `estimatesmartfee` as a floor, so if node restarts, it starts naively giving out min incremental feerate
5) In `estima
...

💬 hebasto commented on pull request "msvc: Cleanup after upgrading libsecp256k1 up to 0.3.0":
(https://github.com/bitcoin/bitcoin/pull/27580#issuecomment-1538509995)
@pinheadmz
> Actually I still get the untracked files warning after merge -- am i doing something wrong?

Try to clean your local repo first. For example, `git clean -xdff`.

💬 fanquake commented on pull request "refactor (tidy): Fixes after enable-debug configure":
(https://github.com/bitcoin/bitcoin/pull/27353#issuecomment-1538515538)
@TheCharlatan can you update this to drop 3e76aff9d4709f44d6439cd0cbc2fd6c90cae6ab, or I think we could just close this?