📝 instagibbs opened a pull request: "2025 10 bypass checkephemeral"
(https://github.com/bitcoin/bitcoin/pull/33616)
Similar reasoning to https://github.com/bitcoin/bitcoin/pull/33504

During a deeper reorg it's possible that a long sequence of dust-having transactions that are connected in a linear fashion, and currently each subsequent "generation" will be rejected on reorg, even though the dust would be spent usually by another child transaction. This could evict a large amount of competitive fees via normal means.

PreCheck based `PreCheckEphemeralSpends` is left in place because we wouldn't have relay
...

💬 fjahr commented on pull request "refactor: Split multithreaded case out of CheckInputScripts":
(https://github.com/bitcoin/bitcoin/pull/32575#issuecomment-3398490065)
Turning it off and on again finally worked :p

💬 janb84 commented on pull request "build: Bump clang minimum supported version to 17":
(https://github.com/bitcoin/bitcoin/pull/33555#issuecomment-3398591114)
ConceptACK fa0fa0f70087d08fe5a54832b96799bd14293279

PR Sets the clang minimum supported version to 17 and drop some work arounds for clang 16. Given that supported OS-es have already a minimal clang version of 17, this should not be a problem.

Would like to see confirmation that the fuzz test works as expected, by a fuzz specialist.

- code review ✅
- GUIX builds ✅
- normal build ✅
- ran tests ✅

Ps. NixOS 25.05 has Clang version 19 as default.

<details><summary> Guix Build O
...

👍 stickies-v approved a pull request: "refactor: Construct g_verify_flag_names on first use"
(https://github.com/bitcoin/bitcoin/pull/33600#pullrequestreview-3332643263)
ACK faa9d10c84bc6b465cbca266468990cc716b4300

I would prefer the `constexpr` approach, but either approach is acceptable to me.

💬 stickies-v commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2427048878)
An alternative approach would be to use a `constexpr` array and make the whole thing compile-time? As a nice benefit, removes the `FLAG_NAME` macro which imo doesn't simplify things enough to be worth it.

<details>
<summary>git diff on faa9d10c84</summary>

```diff
diff --git a/src/script/interpreter.cpp b/src/script/interpreter.cpp
index abd99fc365..731c0a070f 100644
--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -2163,36 +2163,6 @@ size_t CountWitnessSigOps(con
...

💬 janb84 commented on pull request "rpc, test: fix "internal" label check in importdescriptors and extend test":
(https://github.com/bitcoin/bitcoin/pull/33614#discussion_r2427075461)
NIT: would rather see `internal == true` imho better readability.

```suggestion
if (internal == true && data.exists("label")) {
```

💬 janb84 commented on pull request "rpc, test: fix "internal" label check in importdescriptors and extend test":
(https://github.com/bitcoin/bitcoin/pull/33614#discussion_r2427079894)
NIT: restore this and use the pattern that is used for the rest of the tests. Change the `import_request` slightly e.g:

``` C
self.log.info("Test can import a p2pkh descriptor with internal explicit set to false ")
self.test_importdesc({**import_request, "internal": False}, success=True)
```

💬 waketraindev commented on pull request "rpc, test: fix "internal" label check in importdescriptors and extend test":
(https://github.com/bitcoin/bitcoin/pull/33614#issuecomment-3398759053)
Resolved nits, internal checks for true, test updated.

💬 sipa commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3399048111)
Imagine the following state:

```mermaid
graph BT

g["genesis"];
f["fork_point"];
a["ActiveTip()"];
b["pindexBestKnownBlock"];
l["pindexLastCommonBlock"];
p["P"];
f-->g;
a-->f;
l-->p;
b-->p;
p-->f;
```

In this situation, I think we want to update `pindexLastCommonBlock` to be `P`, but the current code will select `fork_point`. Is this a situation that can occur?

I think that the logic we actually want is selecting the more-work among `LastCommonAncestor(pindexBestKnownBlock
...

💬 ajtowns commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2427318037)
I had a look at this approach too. With C++20, I believe you can ensure the array is sorted at compile time with:

```c++
template<typename V, size_t N>
consteval auto SortedArray(const std::array<V,N>& pairs)
{
std::array<V,N> result = pairs;
std::sort(result.begin(), result.end());
return result;
}
#define FLAG_NAME(flag) std::pair<std::string_view, script_verify_flag_name>{#flag, SCRIPT_VERIFY_##flag}
constexpr auto g_verify_flag_names = SortedArray(std::array{
FLA
...

💬 ajtowns commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2423373072)
`static const auto& mFN = SFNTE();` ?

💬 ajtowns commented on pull request "refactor: Construct g_verify_flag_names on first use":
(https://github.com/bitcoin/bitcoin/pull/33600#discussion_r2427284052)
The value of the `FLAG_NAME` macro is that it makes any typos in the strings that would cause a mismatch with the enum names an immediate compile time error. It also makes it easier to type and easier to review. Massive -1 on dropping it. C++26 reflection would be better, when it's available, of course.

🤔 pablomartin4btc reviewed a pull request: "leveldb: show non-default options during init"
(https://github.com/bitcoin/bitcoin/pull/31644#pullrequestreview-3333105034)
Concept ACK

Perhaps the legend "with options: ..." could be debug log? Ideally in the same line but I don't think we support it actually. As an alternative (haven't tested it) maybe:

```
const bool log_options = LogAcceptCategory(BCLog::LEVELDB, BCLog::Level::Debug);

LogInfo("Opened LevelDB successfully%s",
log_options
? tfm::format(" with options: %s", GetChangedOptions(DBContext()))
: "");
```

📝 ac12644 opened a pull request: "contrib: Fix gen-manpages.py to check build options"
(https://github.com/bitcoin/bitcoin/pull/33617)
The gen-manpages.py script was missing critical build option checks,
causing incomplete man page generation. This commit adds comprehensive
build option detection to ensure all available options are documented.

Changes made:
- Add missing USE_UPNP build option detection (core requirement from #17506)
- Fix grammar error: "Aborting generating..." → "Aborting generation of..."
- Remove unused build options that were listed but not actually used
- Add error handling for missing 'components
...

🤔 sipa reviewed a pull request: "miner: fix empty mempool case for waitNext()"
(https://github.com/bitcoin/bitcoin/pull/33566#pullrequestreview-3333348405)
utACK 8f7673257a1a86717c1d83770dc857fc254df107

⚠️ Christewart opened an issue: "`generatetoaddress` 2-3x slower on v30 compared to v29"
(https://github.com/bitcoin/bitcoin/issues/33618)
Hardware

```
Darwin Chriss-MacBook-Pro.local 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:55 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6031 arm64
```


### v29

```
Bitcoin Core daemon version v29.0.0
Copyright (C) 2009-2025 The Bitcoin Core developers
```

```
$ time bitcoin-cli -regtest generatetoaddress 2000 $(bitcoin-cli -regtest getnewaddress)
0.01s user 0.01s system 0% cpu 1:56.41 total
```

### v30

```
Bitcoin Core daemon version v30.0.0
Copyright (C) 2009-2025 The B
...

💬 mzumsande commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3399660829)
I tried the same on Ubuntu / SSD and didn't see a difference.
Just to make sure: Did you start with an empty datadir and fresh wallet each run?

💬 l0rinc commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3399937858)
I have also measured it a few different ways:

Compiling from source and running it 3 times for `v29.2` vs `v30.30`:
<details>
<summary>generatetoaddress | i9-ssd | x86_64 | Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz | 16 cores | 62Gi RAM</summary>

```bash
VERSIONS="29.2 30.0"; \
BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinRegtestData"; LOG_DIR="$BASE_DIR/logs"; \
git fetch origin --tags && \
for v in $VERSIONS; do \
echo "Building v$v..."; \
git checkout v$v && \
rm -rf build-$v
...

💬 l0rinc commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3399998620)
It seems the commit that changed the behavior was https://github.com/bitcoin/bitcoin/commit/7bacabb204b6c34f9545f0b37e2c66296ad2c0de (cc: @achow101)

<details>
<summary>Reproducer</summary>

COMMITS="9a05b45da60d214cb1e5a50c3d2293b1defc9bb0,7bacabb204b6c34f9545f0b37e2c66296ad2c0de"; \
BASE_DIR="/Users/lorinc/IdeaProjects/bitcoin"; \
DATA_DIR="$BASE_DIR/BitcoinRegtestData"; \
mkdir -p "$DATA_DIR" && \
for c in ${COMMITS//,/ }; do \
echo "Building commit $c..."; \
git checkout $c && \
rm -rf
...

⚠️ besoeasy opened an issue: "Proposal to Revert OP_RETURN Mempool Policy Relaxation for Enhanced Network Integrity and User Consensus"
(https://github.com/bitcoin/bitcoin/issues/33619)
**Proposal to Revert OP_RETURN Mempool Policy Relaxation for Enhanced Network Integrity and User Consensus**

As a concerned Bitcoin user and node operator, I'm proposing a rollback of the recent changes to OP_RETURN mempool policies introduced in Bitcoin Core v0.30. These updates significantly increased the default data carrier size (from 80 bytes to 100,000 bytes) and made it configurable, which has sparked widespread community backlash due to concerns over blockchain bloat, spam proliferation
...