💬 maflcko commented on pull request "test: Fix test by checking the actual exception instance":
(https://github.com/bitcoin/bitcoin/pull/28989#issuecomment-1837981733)
lgtm ACK 55e3dc3e03510e97caba1547a82e3e022b0bbd42

📝 maflcko opened a pull request: "ci: Use Ubuntu 24.04 Noble for tsan,tidy,fuzz"
(https://github.com/bitcoin/bitcoin/pull/28992)
23.10 will be EOL mid next year, so a bump is needed before then for the `master` branch (and possibly the `26.x` branch).

Doing the bump now is fine, because the clang version is pinned to 17 inside the CI tasks. So a default clang version change in the system image should not affect the tasks. Once clang-18 is available and the default in April next year (https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649#planned-and-potentially-disruptive-archive-wide-activities-2), the pin
...

💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/28765#issuecomment-1838126153)
Addressed all comments. Ready for review.

💬 maflcko commented on issue "p2p_filter intermittent failure (assert not filter_peer.tx_received)":
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838244265)
Locally: https://drahtbot.space/temp_scratch/p2p_filter_2.tar.xz

💬 fanquake commented on issue "getrawtransaction xxxxxx.... 2 causes a segfault":
(https://github.com/bitcoin/bitcoin/issues/28986#issuecomment-1838271681)
> configurations commands for the build shown above are incorrect, should be....

Note that you are passing options to configure that will have no effect.
`--enable-glibc-back-compat` no-longer exists, and will do nothing.
`--enable-cxx` is not one of our configure options, so will also do nothing (might have been copy-pasted from a BDB configure?).
I would suggest switching `--prefix=xxx` for `CONFIG_SITE=xxx ./configure your-other-options`.

> CPPFLAGS="-fPIC -O2 --param ggc-min-expand=
...

💬 maflcko commented on issue "p2p_filter intermittent failure (assert not filter_peer.tx_received)":
(https://github.com/bitcoin/bitcoin/issues/25128#issuecomment-1838273450)
> However, from the log it looks like the p2p_lock was intermittently released in the on_message function??
>
> ```
> test 2022-12-30T09:33:48.464000Z TestFramework (INFO): Check that request for filtered blocks is ignored if no filter is set
> test 2022-12-30T09:33:48.288000Z TestFramework.p2p (DEBUG): Received message from 127.0.0.1:12488: msg_tx(tx=CTransaction(nVersion=2 vin=[CTxIn(prevout=COutPoint(hash=17576cfafe2ea026d9ab00f6082fe7cc81caf31f5060a1872693f5bf73bf6b11 n=0) scriptSi
...

🚀 fanquake merged a pull request: "[26.0] Finalize or rc4"
(https://github.com/bitcoin/bitcoin/pull/28959)

✅ fanquake closed an issue: "26.0 RC Testing Guide Feedback"
(https://github.com/bitcoin/bitcoin/issues/28866)

💬 fanquake commented on issue "26.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/28866#issuecomment-1838330241)
v26.0 has been tagged. Closing this issue.

✅ fanquake closed an issue: "v26.0 Testing"
(https://github.com/bitcoin/bitcoin/issues/28718)

💬 fanquake commented on issue "v26.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/28718#issuecomment-1838331821)
v26.0 has been tagged. Closing this issue.

💬 fanquake commented on issue "Release schedule for 26.0":
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1838337143)
https://github.com/bitcoin/bitcoin/releases/tag/v26.0 has now been tagged.

💬 maflcko 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-1838382894)
Removed from the 26.0 milestone. https://github.com/bitcoin/bitcoin/pull/28985 looks a bit large to backport, so I guess the fuzz target will be disabled on 26.x and the issue remains?

💬 hebasto commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838426302)
> Also seems fine if you don't want to cherrypick it here, since it's not directly related to this PR and might make it more confusing. I'm happy to open a new PR or review one if it doesn't get cherrypicked.

@ryanofsky

Please do. Thank you.

💬 fanquake commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838429144)
I'll just reopen my PR then. Not sure we need a third PR, for what is a really straightforward bugfix.

📝 fanquake reopened 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
...

💬 dergoegge commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413770472)
The idea is that `m_index` is always set to the next index in `m_offsets` that gets written to (so a value out of `[0, N)`) and we just assume that the initial N samples were 0, which is why the median is immediately computed out of N.

I could change it to always increase `m_index` instead and add new offsets by doing `m_offsets[m_index % N] = new_offset`, in which case your suggestion would allow us to compute the median more "accurately" while we haven't seen N samples yet. I'm not sure tho
...

💬 dergoegge commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1413773031)
Hm yea I guess... I could also just remove support for odd `N`s from this class.

💬 Sjors commented on pull request "Move log messages: tx enqueue to mempool, allocation to blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27277#issuecomment-1838518274)
Rebased after #28368.

💬 martinus commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1413803359)
The m_flags member here causes padding, when you move the member down above/below `flags` you should be able to save 8 bytes from the struct, then you can cache a bit more

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1413826104)
Sure. Will do if I have to retouch.
The number is to test the blocks download procedure and its moving window.
For instance, if the peer is at block 100, and it mines 300 blocks (288 + 12). The test verifies the node only download the blocks that are below the threshold from the limited peer (last 288 blocks minus the buffer). Then, the test connects a full node and it checks the node download the remaining historical blocks from it.