💬 kashifs commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389939970)
I've opened a PR. Please let me know if it's done correctly and if there is more that I should do.

💬 TheCharlatan commented on pull request "depends: remove `PYTHONPATH` from config.site":
(https://github.com/bitcoin/bitcoin/pull/28845#issuecomment-1806474583)
Concept ACK

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389968548)
`depth > 0 || (depth == 0 && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or: must not be (block) conflicted, and it must not be abandoned, for the corresponding output to be considered spent.

`mit->second.isConfirmed() || mit->second.InMempool() || (mit->second.isInactive() && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or in the mempool, or: must be inactive and not abandoned for the corresponding
...

👍 theStack approved a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725729898)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180

🤔 mzumsande reviewed a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725745992)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180, good find!

👍 TheCharlatan approved a pull request: "depends: remove `PYTHONPATH` from config.site"
(https://github.com/bitcoin/bitcoin/pull/28845#pullrequestreview-1725750947)
ACK 95aab1f02784e5d92572ccfcd4ce27107e4b2888

There is nothing in that path anymore.

Guix builds (x86_64)
```
92c922498b9d7e68742355653cc84317d0f0947e8fdd012488c9875e8b54e03c guix-build-95aab1f02784/output/aarch64-linux-gnu/SHA256SUMS.part
634a6a7a82efcb86eb7e875aa4534bd5646e80ee21e951d9624ca7ff78fc82f5 guix-build-95aab1f02784/output/aarch64-linux-gnu/bitcoin-95aab1f02784-aarch64-linux-gnu-debug.tar.gz
2dd4305e325723cac4b0b8e1803d48f3d7eb6fa2fd49c0a980ff907bb3e5da2b guix-build-95aab1
...

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389995261)
Because `tx3` replaced `tx2`, so `tx1` is now `TxStateInactive` instead of `TxStateMempoolConflicted`, making `unspents[0]` spent.

⚠️ luke-jr opened an issue: "Manpage for `-par` bolds lower bound"
(https://github.com/bitcoin/bitcoin/issues/28850)
```
\fB\-par=\fR<n>
.IP
Set the number of script verification threads (\fB\-10\fR to 15, 0 = auto, <0 =
leave that many cores free, default: 0)
```

`\fB` makes the `-10` bold, as if it were a parameter rather than a value.

(Additionally, the `-10` comes from the system of whoever ran the gen-manpages script, and should probably be generated deterministically here...)

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390030476)
Hmm, that will only happen when the node is close to the tip, because of the 1024 block download window. More precisely, when the node is within 1312 blocks from the tip (window + limited peers threshold). Nice observation!.
Will modify it and add coverage for it.

📝 hebasto opened a pull request: "build: Patch Qt to handle minimum macOS version properly"
(https://github.com/bitcoin/bitcoin/pull/28851)
This PR is:
- required to [switch](https://github.com/bitcoin/bitcoin/pull/28622) to macOS 14 SDK (Xcode 15).
- an alternative to https://github.com/bitcoin/bitcoin/pull/28732 and https://github.com/bitcoin/bitcoin/pull/28775.

Qt relies on the `__MAC_OS_X_VERSION_MIN_REQUIRED` macro, which is set in the `AvailabilityInternal.h` SDK header to
the value provided by the Clang driver from the `-mmacos-version-min` / `-mmacosx-version-min` option.

Xcode 12 SDK expects the OS-specific `__ENVI
...

💬 hebasto commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28775#issuecomment-1806576609)
Closing in favour of https://github.com/bitcoin/bitcoin/pull/28851.

✅ hebasto closed a pull request: "build: Patch Qt to handle minimum macOS version properly"
(https://github.com/bitcoin/bitcoin/pull/28775)

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1390055024)
These two things are not technically equivalent, because `send` creates a change output here, which results in intermittent failures for the rest of the test. Is there any way to tell `send` not to create a change output?

💬 ajtowns commented on pull request "[refactor] Remove BlockAssembler m_mempool member":
(https://github.com/bitcoin/bitcoin/pull/28843#discussion_r1390058040)
Why aren't you just changing `addPackageTxs` to use `m_mempool` directly? Seems simpler, and doesn't change the public api. Something like https://github.com/ajtowns/bitcoin/commit/944d8bc87690389de9bd51a6ea8a3223d10e4002#diff-352b412a72c7d069b77b786164c6681ee324ff0d8e61f01d48057e297db991fa

💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1390071466)
I think that `TxStateBlockConflicted` and `TxStateMempoolConflicted` are a bit more clear, because with something like `TxStateUnconfirmedConflict` instead of `TxStateMempoolConflicted`, it is unclear whether the conflict is in the mempool, or just hasn't been broadcasted yet. Additionally, I felt that it was more uniform with the other transaction states to be describing the state of the transaction instead of the state of a conflict. Eg. `TxStateBlockConflicted` indicates that the transaction
...

🤔 furszy reviewed a pull request: "p2p: make block download logic aware of limited peers threshold"
(https://github.com/bitcoin/bitcoin/pull/28120#pullrequestreview-1725862532)
Updated per feedback, thanks for the review @vasild!

The node will now request blocks within the limited peers threshold when the block download window contemplates them and not only when the previous blocks arrived or are in-flight. Have added test coverage exercising this behavior and verifying that the node can get synced even when the blocks arrived out of order.

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390079370)
Removed the unconditional wait on the last update :).

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390075262)
Ended up doing it in a slightly different way. Using `setnetworkactive` to isolate the full node from the other two. I think that is clearer in this way.

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390079461)
Added `NODE_NETWORK_LIMITED_MIN_BLOCKS` on the last update.

💬 Abuchtela commented on pull request "Add support for "partial" fuzzers that indicate usefulness":
(https://github.com/bitcoin/bitcoin/pull/27552#issuecomment-1806630463)
`Rebase`