💬 RandyMcMillan commented on pull request "Feature: Use different datadirs for different signets":
(https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2047513627)
Make sure this PR is based on a passing (CI) commit.

💬 epompeii commented on issue "Continuous benchmark tracking":
(https://github.com/bitcoin/bitcoin/issues/27284#issuecomment-2047551283)
> A sample dashboard is [here](https://bencher.dev/console/projects/0xb10c-s-bitcoin-core/perf?key=true&reports_per_page=4&branches_per_page=8&testbeds_per_page=8&benchmarks_per_page=8&reports_page=1&branches_page=1&testbeds_page=1&benchmarks_page=1&report=915c1007-33dd-4d30-b9c1-531b60af8a06&branches=0ab6caf7-716b-4a6e-8101-f2b9c891a9a2&testbeds=3c0c4d9d-b40e-4d9a-a462-2379355b0785&benchmarks=993b5444-b391-43dd-a4c1-c157cb1d7209%2Cb5ce5b17-6755-449b-b205-b843a0252344%2Cd1b7da67-b22c-4d30-b946-b
...

✅ achow101 closed an issue: "Can't version 26.1 export Bech32 address private key?"
(https://github.com/bitcoin/bitcoin/issues/29836)

💬 sr-gi commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#issuecomment-2047613487)
> Regarding this comment, I tried this refactor and the tests pass.

Thanks! I think I may have been locking the `p2p_lock` twice which made test timeout.

💬 sr-gi commented on pull request "test: Extends wait_for_getheaders so a specific block hash can be checked":
(https://github.com/bitcoin/bitcoin/pull/29736#issuecomment-2047665322)
I wonder if it may be worth splitting the `wait_for_getheaders` function so the internal function can also be used externally, so we can use that to check for whether a certain message exists without waiting for them (e.g. checking for the negative case) in a similar fashion as done in bc844fd8a7d130bfb7cf598f5b1acd87acd70e58

This way we would get rid of a bunch of manual checks like:

```python
with p2p_lock:
assert "getheaders" not in peer.last_message
```

cc/ @maflcko @stratosp
...

👍 BrandonOdiwuor approved a pull request: "test: Extends wait_for_getheaders so a specific block hash can be checked"
(https://github.com/bitcoin/bitcoin/pull/29736#pullrequestreview-1991823634)
crACK c4f857cc301d856f3c60acbe6271d3fe19441c7a

💬 murchandamus commented on pull request "[DO NOT MERGE] testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2047673316)
Since some people consider the blockstorms an interesting feature of Testnet3, it might be interesting to only raise the difficulty of the delayed block exception to 100,000 instead of 1,000,000. This would allow the network to return to the organic difficulty in fewer difficulty periods and slow down the blockstorms but not remove the feature altogether. My understanding is that this would correspond roughly a tenth of one S9 mining on the network, so if no one had mined for a while, a single S
...

💬 maflcko commented on pull request "rpc: validate fee estimation mode case insensitive":
(https://github.com/bitcoin/bitcoin/pull/29175#issuecomment-2047676950)
This is probably more than you wanted to do, but I'd say it would be better to use `FeeModeFromString` to re-use the existing (case-insensitive) parsing code, than to re-implement the parsing and use hard-coded "unset" strings in all call places.

💬 rkrux commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559533843)
Note: This will pop from last message via `check_last_getdata()` call as well, which is different from previous commits. That's why I accepted `last_data` as an argument in my suggestion.
Is popping in `check_last_getdata` also fine?

💬 sr-gi commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559541059)
Yeah, I noticed that on your suggestion, but I don't think we do reuse the value in any test (same as with `wait_for_*`)

💬 willcl-ark commented on issue ""Rolling forward" at startup can take a long time, and is not interruptible":
(https://github.com/bitcoin/bitcoin/issues/11600#issuecomment-2047703916)
The next step here is to make it interruptable.

✅ willcl-ark closed an issue: "bitcoin core crashes when too many rpc calls are made"
(https://github.com/bitcoin/bitcoin/issues/11368)

💬 willcl-ark commented on issue "bitcoin core crashes when too many rpc calls are made":
(https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-2047705793)
The problem is not easily reproducible.

Please open a new issue (or leave a comment in here if you want this re-opened) if you experience the problem again.

💬 fanquake commented on pull request "guix: replace GCC unaligned VMOV patch with binutils patch":
(https://github.com/bitcoin/bitcoin/pull/29846#issuecomment-2047707127)
> Will this close https://github.com/bitcoin/bitcoin/issues/28413 ?

Not quite, we don't yet have a check. I'd still like to add one, but given we've still got occurances, we'd currently have to add exceptions in some way.

💬 willcl-ark commented on issue "bumpfee behavior with "Subtract fee from amount"":
(https://github.com/bitcoin/bitcoin/issues/11122#issuecomment-2047714288)
@achow101 is this fixed by https://github.com/bitcoin/bitcoin/issues/22007 ?

✅ willcl-ark closed an issue: "Prune-to mode (removable blockchain storage)"
(https://github.com/bitcoin/bitcoin/issues/10929)

💬 willcl-ark commented on issue "Prune-to mode (removable blockchain storage)":
(https://github.com/bitcoin/bitcoin/issues/10929#issuecomment-2047717121)
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Pull requests with improvements are always welcome.

💬 willcl-ark commented on issue "listsinceblock incorrectly showing some conflicted transactions":
(https://github.com/bitcoin/bitcoin/issues/10656#issuecomment-2047727910)
@ishaanam is this fixed by your recent mempool conflicted PR?

💬 willcl-ark commented on issue "Add "effective fee rate" in rpc's mempool entries":
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047733917)
Ping @murchandamus, does this work with MiniMiner now?

💬 glozow commented on issue "Add "effective fee rate" in rpc's mempool entries":
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047741492)
> Ping @murchandamus, does this work with MiniMiner now?

It does, can probably implement this for `getmempoolentry`. Just need to handle `GatherClusters` potentially running up against the mempool limit.