💬 Sjors commented on pull request "validation: log which peer sent us a header":
(https://github.com/bitcoin/bitcoin/pull/27826#discussion_r1413831223)
I can reproduce the issue. When the nodes catches up, for a small fraction of blocks it says "Saw new header via unsolicited block". The header refers to a block that was already connected, sometimes more than 25 blocks ago.

💬 andrewtoth commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1413832532)
Ah yes, it makes sense what `num_historical_blocks` purpose is. The nit is why the number 12 was chosen specifically. I suppose to just make it an even 300, and it can be arbitrary?

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1413837545)
> Ah yes, it makes sense what `num_historical_blocks` purpose is. The nit is why the number 12 was chosen specifically. I suppose to just make it an even 300, and it can be arbitrary?

Yep.

💬 fanquake commented on issue "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed":
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838588474)
> will be disabled on 26.x and the issue remains?

Yea, #28985 just arrived way to late for 26.x, and it's still draft, tests failing, no review yet etc. I agree that as-is, it looks too big to backport, maybe it can be done in a way where there is 1 or 2 commits that can be cleanly cherry-picked to fix the issue in the release branch.

💬 furszy commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1413843279)
@naumenkogs, do you agree on the naming as well? I'm happy to change it if we all agree.
Better to be sync to not circle much around the naming here.

💬 furszy commented on issue "Wallets should update key/descriptor birthdates when txs older than current birthdates are found":
(https://github.com/bitcoin/bitcoin/issues/28897#issuecomment-1838608012)
#28920 solves it. In case someone else wants to try it.

💬 furszy commented on issue "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed":
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838626406)
> > will be disabled on 26.x and the issue remains?
>
> Yea, #28985 just arrived way to late for 26.0, and it's still draft, tests failing, no review yet etc. I agree that as-is, it looks too big to backport, maybe it can be done in a way where there is 1 or 2 commits that can be cleanly cherry-picked to fix the issue in the release branch.

Could cherry-pick the bugfix (a38f5856edaf843cf25e8dead1c96f93daea77a4), the bugfix test (aa3b971320ee7b0c8effd105681709f18f07eb63, 0bae09423676f6be842
...

📝 hebasto converted_to_draft a pull request: "depends: Build the `native_capnp` and `capnp` packages with CMake"
(https://github.com/bitcoin/bitcoin/pull/28856)
This change fixes the `x86_64-w64-mingw32` build (see https://github.com/bitcoin/bitcoin/pull/28735#issuecomment-1790406668) and simplifies the configuration file.

💬 fanquake commented on issue "Release schedule for 26.0":
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1838646087)
I've closed the 26.0 milestone. Will close this issue once Guix builds are done, and binaries are available on bitcoincore.org.

⚠️ fanquake unpinned an issue: "v26.0 Testing"
(https://github.com/bitcoin/bitcoin/issues/28718)
Umbrella issue for 26.0 testing. Please help testing on a wide variety of supported platforms, as well as interaction with different software.

Let us know which version you tested on which operating system.

If you find an issue, please search Github for known issues first and then open a new Github issue.

*This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.*

See [26.0 Draft Release Notes](https://github.com/bitcoin-c
...

💬 Sjors commented on pull request "validation: log which peer sent us a header":
(https://github.com/bitcoin/bitcoin/pull/27826#discussion_r1413916982)
I solved the second issue by setting `/*via_unsolicited_block=*/!is_block_requested` (renamed `forceProcessing`). I'll push that in a bit.

I'm still debugging the first issue. E.g an example log during IBD, with `-debug=net -debug=validation -loglevel=validation:debug`:

```
2023-12-04T13:47:10Z Synchronizing blockheaders, height: 819750 (~100.00%)
2023-12-04T13:47:10Z [validation:debug] Saw new header hash=00000000000000000002d311ad8da2e7551130798984e20c87b8156c3d27d261 height=819750 pee
...

💬 Sjors commented on pull request "validation: log which peer sent us a header":
(https://github.com/bitcoin/bitcoin/pull/27826#discussion_r1413928471)
Ah, but that documentation is wrong. `ProcessBlock` only tells us if the _block_ is new, not if the header is new. The latter _is_ checked by `AcceptBlockHeader`, but not returned.

💬 murchandamus commented on issue "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed":
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838723096)
Sure, go ahead!

💬 Sjors commented on pull request "validation: log which peer sent us a header":
(https://github.com/bitcoin/bitcoin/pull/27826#issuecomment-1838743265)
Only keeping the first commit.

I don't want to make this PR more complicated. If anyone wants to try detecting new headers that arrive via an unsolicited block, see the following dropped commits: 386febd59bd894ad9c5216eacafe0308ed314980 and 708600f3b7df4cf166a2fcdfd3c0dc70b70812f0.

💬 Sjors commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1838752940)
Running into a build error with 78859dc3338f5dfd4f80452722e0c39ec6f68656:

```
compiling tools/qmap.cpp
In file included from global/qoperatingsystemversion.cpp:46:
In file included from ../../include/QtCore/5.15.11/QtCore/private/qcore_mac_p.h:1:
../../include/QtCore/5.15.11/QtCore/private/../../../../../src/corelib/kernel/qcore_mac_p.h:68:10: fatal error: 'CoreFoundation/CoreFoundation.h' file not found
#include <CoreFoundation/CoreFoundation.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

✅ gianlucamazza closed an issue: "bitcoin core crashes and restarts syncing from beginning "
(https://github.com/bitcoin/bitcoin/issues/28795)

💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1838758831)
Should be fixed now. Forgot that, we neeed to revert to including basically the entire SDK here, to accomodate Qt.

⚠️ hebasto opened an issue: "`capnp` fails when cross-compiling"
(https://github.com/bitcoin/bitcoin/issues/28993)
On the master branch @ 160d23677ad799cf9b493eaa923b2ac080c3fb8e, the `native/bin/capnp` fails when cross-compiling with `MULTIPROCESS=1`:
```
GEN /home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/include/mp/proxy.capnp.h
/home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/include/mp/proxy.capnp: File is not in the current directory and does not match any prefix defined with --src-prefix. Please pass an appropriate --src-prefix so I can figure out where to write the output for thi
...

💬 hebasto commented on issue "`capnp` fails when cross-compiling":
(https://github.com/bitcoin/bitcoin/issues/28993#issuecomment-1838761432)
cc @ryanofsky

👋 hebasto's pull request is ready for review: "depends: Build the `native_capnp` and `capnp` packages with CMake"
(https://github.com/bitcoin/bitcoin/pull/28856)