💬 tdb3 commented on issue "ci: `feature_settings.py` failed in macOS 14 CI":
(https://github.com/bitcoin/bitcoin/issues/31019#issuecomment-2394376294)

> The node is expected to fail with `Invalid value detected for '-wallet' or '-nowallet'` (that's what the test is testing), so that's not the problem.

Right, the title was poorly worded. Updated

💬 davidgumberg commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2394400423)
I cherry picked your branch onto master and did two runs syncing from a stable, dedicated local node twice on a Raspberry Pi 5 4GB using microSD for storage, with a prune of `2000` and the default dbcache using the following command:

```
./build/src/bitcoind -daemon=0 -connect=ryzen7900xnode:8333 -stopatheight=800000 -prune=2000 -debug=bench -debug=blockstorage -debug=coindb -debug=mempool -debug=prune
```

I saw a *massive* improvement, with your branch taking, on average, **~6
...

💬 davidgumberg commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#discussion_r1788273274)
non-blocking out-of-scope: Might be worth it to either deprecate true/false values for verbosity arguments or introduce an argument type specific to verbosity arguments to avoid skipping type checks for them.

💬 achow101 commented on pull request "Dialog for allowing the user to choose the change output when bumping a tx":
(https://github.com/bitcoin-core/gui/pull/700#discussion_r1788273291)
Done

💬 achow101 commented on pull request "Dialog for allowing the user to choose the change output when bumping a tx":
(https://github.com/bitcoin-core/gui/pull/700#issuecomment-2394515614)
Rebased and fixed the build issue in the first commit.

💬 tdb3 commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#discussion_r1788275942)
I would support either, with the latter being my preference (at least initially/in transition)

💬 0xB10C commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394709587)
Interesting idea - I remember that we briefly chatted about this a while ago.

How does this behave during e.g. IBD when a "good" peer sends us a bunch of blocks and we spent a lot of CPU time validating them? Does something like this need to be excluded? I guess it's similar for peers that constantly send us transactions we don't know about yet (maybe because they are just better connected or they are broadcasting them) - not sure if we want to process their messages slower.

💬 hodlinator commented on pull request "descriptor: Add proper Clone function to miniscript::Node":
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788379490)
The PR description asserts:
> Multipath descriptors requires performing a deep copy

Would be happy if you cared to add an elaboration on why that is.

It seemed to me like it should be safe to just have another `shared_ptr` point to the same `const Node`. Unless something on the outside could own a non-const reference into the node hierarchy and mutate it that way? In that case maybe it would be more robust for the `MiniscriptDescriptor`-ctor to be the one ensuring it holds a unique refere
...

💬 russeree commented on pull request "Enhanced error messages for invalid network prefix during address parsing.":
(https://github.com/bitcoin/bitcoin/pull/27260#discussion_r1788394254)
> [7478ac6](https://github.com/bitcoin/bitcoin/commit/7478ac6af922c302e292ace7f61e6eaa461da727): this change belongs in the previous commit [07f9733](https://github.com/bitcoin/bitcoin/commit/07f9733e6022d77d755321914a2a2a1dd7ce0d59)
>
> (One way to move it there is by doing `git rebase -i HEAD~3`, setting "e" for the first commit, and then add these lines. Then you do a `git commit -a --amend` to update the first commit. Then `git rebase --continue`, which should automatically adjust the sec
...

💬 russeree commented on pull request "Enhanced error messages for invalid network prefix during address parsing.":
(https://github.com/bitcoin/bitcoin/pull/27260#issuecomment-2394760664)
> Re last commit message, you can leave this out:
>
> > A complete refactor of the previous pull to simplify logic and reduce the
> > chance of technical debt.

This has been removed.

💬 fjahr commented on issue "assumeutxo: not syncing the snapshot chainstate":
(https://github.com/bitcoin/bitcoin/issues/30971#issuecomment-2394768306)
> If this gets to the point that the snapshot load completes, I'll close this.

I don't think we have to close this right away, we can keep this open for a few more weeks to see if this issue occurs for other users. Having an open issue already makes it easier for people to engage. But did loading of the snapshot actually complete eventually @fanquake ?

I am currently looking into the obfuscation key because I find it suspicious that it changes for `chainstate_snapshot`. From my understand
...

🤔 promag reviewed a pull request: "qt6: Handle different signatures of `QANEF::nativeEventFilter`"
(https://github.com/bitcoin-core/gui/pull/840#pullrequestreview-2349357223)
I think small changes to make code compatible with both versions are fine until support for qt5 is dropped.

Code review ACK 80761afced12c774a1768fb27a3975d456981ae0.

Alternative is to use type alias
```cpp
#if (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0))
using result_t = qintptr*;
#else
using result_t = long*;
#endif

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2394777591)
Guix builds for the recent push:
- `aarch64`:
```
ad3093fa02114e2ec80b54312ff0df232893dc73395630c3d7fdb34d7fe79d83 guix-build-b0322c462106/output/aarch64-linux-gnu/SHA256SUMS.part
d0b95a6538bb8ad217dcbf6cf481d9849d8a9b0c40ca18717cd3594087a5a5a5 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-linux-gnu-debug.tar.gz
d85f9ce2e9ffb310d55fcc4b9755a52d33935bb742f460fc7b6b74b61bad35a3 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-lin
...

🤔 promag reviewed a pull request: "Fix display issues for IPv6 proxy setup in Options Dialog (UI only, no functionality impact)"
(https://github.com/bitcoin-core/gui/pull/836#pullrequestreview-2349362315)
Code review ACK fee4cba48472239f7a426db62f45c4b6af8e5ef2.

📝 achow101 opened a pull request: "[28.x] doc: Sync 28.0 release notes with website"
(https://github.com/bitcoin/bitcoin/pull/31034)
Since there were some changes to the release notes after the tagging, update the in branch release notes to match those that ended up on the website.

📝 achow101 opened a pull request: "doc: Archive 28.0 release notes"
(https://github.com/bitcoin/bitcoin/pull/31035)
Matches the release notes on the website.

💬 achow101 commented on pull request "descriptor: Add proper Clone function to miniscript::Node":
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788418189)
It's not strictly necessary but I decided to do it this way to follow the pattern used for all other descriptors. The multipath expanded descriptors are treated as separate descriptors everywhere, and doing a deep copy retains that behavior which will allow for future changes that may modify specific descriptors.

⚠️ vasild opened an issue: "Listen on random port by default (not 8333)"
(https://github.com/bitcoin/bitcoin/issues/31036)
### Please describe the feature you'd like to see added.

Connections to port 8333 can be recognized right away as Bitcoin P2P connections. While it is still possible to recognize Bitcoin P2P connections regardless of the port, random ports would make network-wide monitoring harder.


### Is your feature related to a problem, if so please describe it.

Network-wide monitoring.

### Describe the solution you'd like

The listening address and port of a node are propagated and saved in other nodes
...

💬 vasild commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394932171)
Good questions that I do not have an answer to.

I guess this should start with planting some metrics - CPU time used by each peer in the last 1, 5 and 15 minutes and assessing what a "usual" situation looks like.

Specific to CPU DoS via invalid transactions: for peers that send us such transactions, maybe multiply the CPU time by a factor e.g. 10x or 100x. Or the other way around - nullify CPU time spend on definitely-good-and-positive things like new blocks or new transactions that we acc
...

💬 azazar commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2394951796)
The Testnet is becoming more frustrating. Testnet coins are nearly impossible to get without an ASIC, and now sending them has become a hassle too.