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

👍 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.