💬 fanquake commented on pull request "build: switch to using LLVM 17.x for macOS builds":
(https://github.com/bitcoin/bitcoin/pull/28880#issuecomment-1846855849)
Ok. I think this was broken in 17.x, in this change https://github.com/llvm/llvm-project/commit/1f173a0653e7f0c3800033edfa16ffe4c35cde85. You should be able to build 16.x. i.e `guix build --target=riscv64-linux-gnu llvm@16.0.6`. This is something we should be able to fixup/patch around.

💬 maflcko commented on pull request "test: test_bitcoin: allow -testdatadir=<datadir>":
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1420176846)
Maybe submit this (bugfix? or change?) in a separate pull?

👍 theStack approved a pull request: "wallet: batch all individual spkms setup db writes in a single db txn"
(https://github.com/bitcoin/bitcoin/pull/28894#pullrequestreview-1771968085)
Code-review ACK f05302427386fe63f4929a7198652cb1e4ab3bcc

💬 maflcko commented on pull request "build: switch to using LLVM 17.x for macOS builds":
(https://github.com/bitcoin/bitcoin/pull/28880#issuecomment-1846869958)
See also https://reviews.llvm.org/D137799#4657404

Did you have steps to reproduce outside of guix?

👍 theStack approved a pull request: "test: Extends MEMPOOL msg functional test"
(https://github.com/bitcoin/bitcoin/pull/28485#pullrequestreview-1772011203)
re-ACK 97c0dfa8942c7fd62c920deee03b4d0c59aba641

💬 naumenkogs commented on pull request "p2p: attempt to fill full outbound connection slots with peers that support tx relay":
(https://github.com/bitcoin/bitcoin/pull/28538#discussion_r1420214407)
sounds good

💬 naumenkogs commented on pull request "p2p: attempt to fill full outbound connection slots with peers that support tx relay":
(https://github.com/bitcoin/bitcoin/pull/28538#discussion_r1420216477)
the idea was to log `if maxconnect is set to 1`, so at the startup (setting this argument) time.
I don't insist though.

💬 naumenkogs commented on pull request "p2p: attempt to fill full outbound connection slots with peers that support tx relay":
(https://github.com/bitcoin/bitcoin/pull/28538#issuecomment-1846900239)
ACK 840a022

Not sure if you noticed [this idea](https://github.com/bitcoin/bitcoin/pull/28538#discussion_r1417175382), might be a worthy precaution.

📝 brunoerg opened a pull request: "wallet: fix key parsing check for miniscript expressions"
(https://github.com/bitcoin/bitcoin/pull/29027)
In `ParseScript`, when processing miniscript expressions, the way we check for key parsing error is wrong, the actual code is unreachable because we're checking it into `if (node)` (successful parsing) statement.

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420231148)
I'm not sure it is a good idea to have two calls to `fuzzed_data_provider` in the function call. The problem is that the order of evaluation of function arguments is unspecified: https://en.cppreference.com/w/cpp/language/eval_order
So evaluation order can change at any time. Then the same fuzzing input will produce different results.
I'd move the calls in front of `NewMempoolTransactionInfo`

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420236394)
I'm not sure it is a good idea to have two calls to `fuzzed_data_provider` in the function call. The problem is that the order of evaluation of function arguments is unspecified: https://en.cppreference.com/w/cpp/language/eval_order
So evaluation order can change at any time. Then the same fuzzing input will produce different results.
I'd move the calls in front of `NewMempoolTransactionInfo`

👋 fanquake's pull request is ready for review: "[26.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/29011)

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#issuecomment-1846919761)
I can confirm that #29000 is fixed for me in commit 76d0c07ee94b8720964d9d71d462550ecc8b5147.

🚀 fanquake merged a pull request: "doc: Add link to needs-release-notes label"
(https://github.com/bitcoin/bitcoin/pull/29025)

👍 dergoegge approved a pull request: "fuzz: p2p: Detect peer deadlocks"
(https://github.com/bitcoin/bitcoin/pull/29009#pullrequestreview-1772081065)
ACK 9f265d88253ed464413dea5614fa13dea0d8cfd5

💬 fanquake commented on pull request "wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction":
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1846934788)
@josibake @furszy want to take another look here.

💬 maflcko commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420254059)
Is there an easy way to catch those somehow in CI?

✅ fanquake closed an issue: "Release schedule for 26.0"
(https://github.com/bitcoin/bitcoin/issues/27758)

💬 fanquake commented on issue "Release schedule for 26.0":
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1846942032)
Closing this now, will open a new timeline for 27.0.

⚠️ fanquake opened an issue: "Release schedule for 27.0"
(https://github.com/bitcoin/bitcoin/issues/29028)
Here is a proposed release schedule for `v27.0`, the next major release of Bitcoin Core. Dates roughly chosen as discussed in the most recent IRC meeting.

## 2024-02-01 🚧
- Open Transifex translations for `v27.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v25.0`

## 2024-02-12 🚧 :
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until
...