📝 fanquake opened a pull request: "depends: fix libmultiprocess build on aarch64"
(https://github.com/bitcoin/bitcoin/pull/28846)
Two changes to improve the libmultiprocess build on aarch64.

First, is to always install libmultiprocess into `lib/`. On some systems (my Fedora aarch64 box), libmultiprocess was being installed into `lib64/`, and then configure would fail to pick it up, because we only add `lib/` to pkgconfig/ldflags out of depends. Rather than adding lib64 to those, I opted for installing libmultiprocess into lib, with every other dependency we build.

Second, is to build with position independant code. T
...

💬 hebasto commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28775#issuecomment-1806115806)
> Another thing to note, is that the code being patched here, has been deleted entirely upstream: [qt/qtbase@329db8b](https://github.com/qt/qtbase/commit/329db8b64f17c8ef013c586cea1f1c5b49c4a4b7).
>
> > macOS: Remove fallback defines for MAC_OS_X_VERSION_MIN_REQUIRED
> > Availability.h from the platform SDK should take care of this these days.
>
> So this points to there still being an underlying issue...

The fact is that the `__MAC_OS_X_VERSION_MIN_REQUIRED` is [_not_](https://github.
...

💬 hebasto commented on pull request "depends: fix libmultiprocess build on aarch64":
(https://github.com/bitcoin/bitcoin/pull/28846#issuecomment-1806128909)
Concept ACK.

💬 fanquake commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28775#issuecomment-1806142446)
> At least, when using the current Clang version in depends.

Right, but why is it suddenly defined when using a newer compiler? Can you point to where in the LLVM/Clang source code this starts happening in versions 16+? It just irks me that updating to a new compiler "magically" fixes things, without explanation.

I think we will likely take this patch as a temporary workaround, just to unblock C++20, but we should probably add some more context to the patch itself. I also dislike having to
...

💬 fanquake commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389692101)
cc @theStack

🤔 glozow reviewed a pull request: "mempool: Persist with XOR"
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1725266416)
reACK fa6b053b5c964fb35935fa994cb782c0731a56f8

💬 theStack commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389710284)
Good catch @kashifs. Do you want to open a PR for the fix? If not (for whatever reason), I'm happy to do it and add the commit with your authorship.

💬 instagibbs commented on pull request "fuzz: Minor improvements to tx_package_eval target":
(https://github.com/bitcoin/bitcoin/pull/28825#discussion_r1389748737)
yes, with the idea that the fuzzer won't be able to generate the preimage to all genuinely create null uint256/prevout

💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1389838929)
I agree that would be nice, in particular so that we can enable `p2p_dos_header_tree.py` (which uses testnet instead of regtest) in combination with v2 transport. One possibility would be to move the `MAGIC_BYTES` constants from `p2p.py` into another file (e.g. `test_framework/messages.py`), change all includes, pass `net` to `EncryptedP2PState`, and change `V1_PREFIX` into a local variable using it)

⚠️ lasermind opened an issue: "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`"
(https://github.com/bitcoin/bitcoin/issues/28847)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Although the blockchain is synced, after some minutes, `bitcoin-cli -getinfo` does not display `verification progress: 100.0000%` any more, but drops to `99.9999%` and even below.

New block arrived:

After two minutes:
![verification-999999-hl](https://github.com/bitcoin
...

💬 pinheadmz commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806420963)
You'll find this question on stack exchange:

https://bitcoin.stackexchange.com/search?q=Progress

It can happen if the most recent block was mined too long ago. Essentially the node can only estimate how many blocks "should be" in the chain given the time. Your node doesn't know if there is a longer chain out there than what it already has, and so "progress" is just a guess.

📝 instagibbs opened a pull request: "Change up submitpackage results"
(https://github.com/bitcoin/bitcoin/pull/28848)
This was prompted by errors being returned that didn't "make any sense" to me, because it would for example return a "fee too low" error, when the "real" error was the child had something invalid, which disallowed CPFP evaluation. Rather than make judgment calls on what error is important, we simply return all errors and let the callers determine what's best.

I'm not sure this is the best format, in that maybe we want to make failure cases more obvious. Maybe failures into its own top-level o
...

💬 lasermind commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806447019)
I'm inclined to agree, that such a "probabilistic decrease" could be done when really the most recent block was mined "too long ago". But it happens regularly even after two minutes. This can't be "too long ago" when it is to assume that a new block happens every 10 minutes.

Also note: I'm **not** talking about the `progress` from the log file, which seems to sit happily at `1.000000`. I'm talking about the `verification progress` value, output by the command `bitcoin-cli -getinfo`, which sta
...

💬 sipa commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806450388)
@lasermind A node is *always* synchronizing. It is never "done", because it cannot know whether a later block was already mined. So the number is just a ratio between the number of blocks it has divided by a guess for how many blocks should exist, on average. Even briefly after a block, it will be less than 100%.

📝 kashifs opened a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849)
fix node index bug when comparing peerinfo in test/functional/p2p_v2_transport.py

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