💬 l0rinc commented on pull request "randomenv: Fix MinGW dllimport warning for `environ`":
(https://github.com/bitcoin/bitcoin/pull/33570#issuecomment-3402151700)
My understanding is that https://github.com/msys2-contrib/mingw-w64/blob/cdb052f1d4056cd510cb83197b55868427b87476/mingw-w64-headers/crt/stdlib.h#L704
expands `environ` to `_environ`, and in https://github.com/msys2-contrib/mingw-w64/blob/cdb052f1d4056cd510cb83197b55868427b87476/mingw-w64-headers/crt/stdlib.h#L262-L264, _environ is further defined as a macro expanding to `(* __p__environ())` (similar problem described in https://github.com/msys2/MINGW-packages/issues/13925#issuecomment-13128204
...
(https://github.com/bitcoin/bitcoin/pull/33570#issuecomment-3402151700)
My understanding is that https://github.com/msys2-contrib/mingw-w64/blob/cdb052f1d4056cd510cb83197b55868427b87476/mingw-w64-headers/crt/stdlib.h#L704
expands `environ` to `_environ`, and in https://github.com/msys2-contrib/mingw-w64/blob/cdb052f1d4056cd510cb83197b55868427b87476/mingw-w64-headers/crt/stdlib.h#L262-L264, _environ is further defined as a macro expanding to `(* __p__environ())` (similar problem described in https://github.com/msys2/MINGW-packages/issues/13925#issuecomment-13128204
...
💬 zaidmstrr commented on pull request "miner: fix empty mempool case for waitNext()":
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429445328)
Using `std::accumulate` in line 526 seems good, but using it in line 530 has some performance impact. `std::accumulate` search for the whole vector despite the condition already being met. With this it increases the best-case time complexity and some average-case complexity from `Ω(k)` (where k <= n) to `Ω(n)`. Any caller calling this with frequent polling might face some milliseconds of performance issues in some cases.
I feel like the approach in commit [2e8fff3](https://github.com/bitcoin/bi
...
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429445328)
Using `std::accumulate` in line 526 seems good, but using it in line 530 has some performance impact. `std::accumulate` search for the whole vector despite the condition already being met. With this it increases the best-case time complexity and some average-case complexity from `Ω(k)` (where k <= n) to `Ω(n)`. Any caller calling this with frequent polling might face some milliseconds of performance issues in some cases.
I feel like the approach in commit [2e8fff3](https://github.com/bitcoin/bi
...
🤔 zaidmstrr reviewed a pull request: "miner: fix empty mempool case for waitNext()"
(https://github.com/bitcoin/bitcoin/pull/33566#pullrequestreview-3336048702)
Concept ACK [8f76732](https://github.com/bitcoin/bitcoin/pull/33566/commits/8f7673257a1a86717c1d83770dc857fc254df107)
(https://github.com/bitcoin/bitcoin/pull/33566#pullrequestreview-3336048702)
Concept ACK [8f76732](https://github.com/bitcoin/bitcoin/pull/33566/commits/8f7673257a1a86717c1d83770dc857fc254df107)
💬 diegoviola commented on issue "Qt6 version of Bitcoin Core (bitcoin-qt) flickers on Wayland":
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402205029)
> Does it look similar to [bitcoin/bitcoin#33432](https://github.com/bitcoin/bitcoin/issues/33432)?
Yes, it does look like the same issue.
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402205029)
> Does it look similar to [bitcoin/bitcoin#33432](https://github.com/bitcoin/bitcoin/issues/33432)?
Yes, it does look like the same issue.
💬 glozow commented on issue "Minor Release 29.2":
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3402216675)
Please review the website PR: https://github.com/bitcoin-core/bitcoincore.org/pull/1183
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3402216675)
Please review the website PR: https://github.com/bitcoin-core/bitcoincore.org/pull/1183
💬 instagibbs commented on pull request "test: Fix reorg patterns in tests to use proper fork-based approach":
(https://github.com/bitcoin/bitcoin/pull/32587#issuecomment-3402220995)
https://github.com/bitcoin/bitcoin/pull/33616#discussion_r2428574156
looks like you forgot to remove the definition from `mempool_updatefromblock.py`
(https://github.com/bitcoin/bitcoin/pull/32587#issuecomment-3402220995)
https://github.com/bitcoin/bitcoin/pull/33616#discussion_r2428574156
looks like you forgot to remove the definition from `mempool_updatefromblock.py`
💬 l0rinc commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3402229976)
I've generated a differential flamegraph comparing the commits before and after the regression:
<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/f739b2ac-0aa8-4ccb-9a84-f3239ffa0d0e" />
and
<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/fa12d922-4d18-4620-9c6d-799376a95179" />
<details>
<summary>Flame graphs</summary>
I've generated a differential flamegraph comparing the commits before and after the regression:
<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/f739b2ac-0aa8-4ccb-9a84-f3239ffa0d0e" />
and
<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/fa12d922-4d18-4620-9c6d-799376a95179" />
<details>
<summary>Flame graphs</summary>
![Image](https://github.com/
...
💬 hebasto commented on issue "Qt6 version of Bitcoin Core (bitcoin-qt) flickers on Wayland":
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402230782)
> So I've just tried the `v30.0` release and I have it up and running on Arch Linux, bitcoin-qt is running natively on Wayland (sway).
Could you please share the first 10 lines of your debug log file?
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402230782)
> So I've just tried the `v30.0` release and I have it up and running on Arch Linux, bitcoin-qt is running natively on Wayland (sway).
Could you please share the first 10 lines of your debug log file?
💬 Raimo33 commented on pull request "miner: fix empty mempool case for waitNext()":
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429469983)
you're talking about theoretical complexity. but I'm almost certain that the `std::accumulate` approach is orders of magnitude faster in practice when you measure absolute time. this is because avoiding a branch at every iteration allows for optimizations such as SIMD vectorization, or even simply a better data access pattern which is more cache friendly.
I'd love to see some benchmarks!
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429469983)
you're talking about theoretical complexity. but I'm almost certain that the `std::accumulate` approach is orders of magnitude faster in practice when you measure absolute time. this is because avoiding a branch at every iteration allows for optimizations such as SIMD vectorization, or even simply a better data access pattern which is more cache friendly.
I'd love to see some benchmarks!
💬 diegoviola commented on issue "Qt6 version of Bitcoin Core (bitcoin-qt) flickers on Wayland":
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402245632)
> > So I've just tried the `v30.0` release and I have it up and running on Arch Linux, bitcoin-qt is running natively on Wayland (sway).
>
> Could you please share the first 10 lines of your debug log file?
```
2025-10-14T14:47:07Z Bitcoin Core version v30.0 (release build)
2025-10-14T14:47:07Z Qt 6.10.0 (dynamic), plugin=wayland
2025-10-14T14:47:07Z No static plugins.
2025-10-14T14:47:07Z Style: fusion / QFusionStyle
2025-10-14T14:47:07Z System: Arch Linux, x86_64-little_endian-lp64
2025-10-1
...
(https://github.com/bitcoin-core/gui/issues/903#issuecomment-3402245632)
> > So I've just tried the `v30.0` release and I have it up and running on Arch Linux, bitcoin-qt is running natively on Wayland (sway).
>
> Could you please share the first 10 lines of your debug log file?
```
2025-10-14T14:47:07Z Bitcoin Core version v30.0 (release build)
2025-10-14T14:47:07Z Qt 6.10.0 (dynamic), plugin=wayland
2025-10-14T14:47:07Z No static plugins.
2025-10-14T14:47:07Z Style: fusion / QFusionStyle
2025-10-14T14:47:07Z System: Arch Linux, x86_64-little_endian-lp64
2025-10-1
...
💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2429481952)
I couldn't get it to work on CI anyway
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2429481952)
I couldn't get it to work on CI anyway
💬 Sjors commented on pull request "miner: fix empty mempool case for waitNext()":
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429496328)
I think the reduced code complexity is worth losing the early return. After cluster cluster mempool this calculation will probably be replaced anyway.
(https://github.com/bitcoin/bitcoin/pull/33566#discussion_r2429496328)
I think the reduced code complexity is worth losing the early return. After cluster cluster mempool this calculation will probably be replaced anyway.
💬 Crypt-iQ commented on pull request "test: change log rate limit version gate":
(https://github.com/bitcoin/bitcoin/pull/33612#discussion_r2429516122)
Thanks, I changed this to 29.1.
(https://github.com/bitcoin/bitcoin/pull/33612#discussion_r2429516122)
Thanks, I changed this to 29.1.
💬 furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#issuecomment-3402327792)
> I also measured the txindex with `-indexworkers=15` on a 32 vcpu machine and it was slightly slower than master. I guess this makes sense since each thread needs to write the index data to leveldb, and the actual work done by the CPU is minimal (serializing then computing offsets). So each thread is waiting for the other threads to finish writing. For blockfilter the filter computation is more intensive, and then each filter is written to a separate file. Only after the filter is written t
...
(https://github.com/bitcoin/bitcoin/pull/26966#issuecomment-3402327792)
> I also measured the txindex with `-indexworkers=15` on a 32 vcpu machine and it was slightly slower than master. I guess this makes sense since each thread needs to write the index data to leveldb, and the actual work done by the CPU is minimal (serializing then computing offsets). So each thread is waiting for the other threads to finish writing. For blockfilter the filter computation is more intensive, and then each filter is written to a separate file. Only after the filter is written t
...
🤔 janb84 reviewed a pull request: "test: change log rate limit version gate"
(https://github.com/bitcoin/bitcoin/pull/33612#pullrequestreview-3336184569)
ACK 7b544341c0021dd713f05bc439ee190de911930c
PR changes version gate for test framework to disable the log rate limiting. The log rate limit change was backported to 29.1. This PR sets gate from v29.99 to v29.01 which has the change.
(https://github.com/bitcoin/bitcoin/pull/33612#pullrequestreview-3336184569)
ACK 7b544341c0021dd713f05bc439ee190de911930c
PR changes version gate for test framework to disable the log rate limiting. The log rate limit change was backported to 29.1. This PR sets gate from v29.99 to v29.01 which has the change.
💬 mzumsande commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3402367045)
> I think that the logic we actually want is selecting the more-work one among `LastCommonAncestor(pindexBestKnownBlock, ActiveTip())` and `LastCommonAncestor(pindexBestKnownBlock, pindexLastCommonBlock)`.
That means a situation where a peer reorged to a different chain compared to the last call, while our tip is on yet a third chain - I agree that it would be better to go to P here. However, it would just be an optimization - without it, we will set `pindexLastCommonBlock` to the `fork_poin
...
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3402367045)
> I think that the logic we actually want is selecting the more-work one among `LastCommonAncestor(pindexBestKnownBlock, ActiveTip())` and `LastCommonAncestor(pindexBestKnownBlock, pindexLastCommonBlock)`.
That means a situation where a peer reorged to a different chain compared to the last call, while our tip is on yet a third chain - I agree that it would be better to go to P here. However, it would just be an optimization - without it, we will set `pindexLastCommonBlock` to the `fork_poin
...
💬 maflcko commented on pull request "test: change log rate limit version gate":
(https://github.com/bitcoin/bitcoin/pull/33612#issuecomment-3402383777)
> In the case a user on 29.x runs the functional tests and is confused why logs are rate limited in output.
This may also help in the future, when a previous release of 29.1 (or later in the 29.x series) is picked.
lgtm ACK 7b544341c0021dd713f05bc439ee190de911930c
(https://github.com/bitcoin/bitcoin/pull/33612#issuecomment-3402383777)
> In the case a user on 29.x runs the functional tests and is confused why logs are rate limited in output.
This may also help in the future, when a previous release of 29.1 (or later in the 29.x series) is picked.
lgtm ACK 7b544341c0021dd713f05bc439ee190de911930c
💬 optout21 commented on pull request "miner: fix empty mempool case for waitNext()":
(https://github.com/bitcoin/bitcoin/pull/33566#issuecomment-3402417850)
ACK 8f7673257a1a86717c1d83770dc857fc254df107
(https://github.com/bitcoin/bitcoin/pull/33566#issuecomment-3402417850)
ACK 8f7673257a1a86717c1d83770dc857fc254df107
💬 Crypt-iQ commented on pull request "test: change log rate limit version gate":
(https://github.com/bitcoin/bitcoin/pull/33612#issuecomment-3402423882)
I was testing out 29.x without this patch and was very confused why the rate limiting was not being applied. Turns out my description in the OP is wrong.
Unless the version is explicitly set as done in the [`wallet_backwards_compatibility.py`](https://github.com/bitcoin/bitcoin/blob/6c4fe401e908cff1b67d80035b117aae15fe7db6/test/functional/wallet_backwards_compatibility.py#L56-L65) test, the [`version_is_at_least`](https://github.com/bitcoin/bitcoin/blob/6c4fe401e908cff1b67d80035b117aae15fe7db
...
(https://github.com/bitcoin/bitcoin/pull/33612#issuecomment-3402423882)
I was testing out 29.x without this patch and was very confused why the rate limiting was not being applied. Turns out my description in the OP is wrong.
Unless the version is explicitly set as done in the [`wallet_backwards_compatibility.py`](https://github.com/bitcoin/bitcoin/blob/6c4fe401e908cff1b67d80035b117aae15fe7db6/test/functional/wallet_backwards_compatibility.py#L56-L65) test, the [`version_is_at_least`](https://github.com/bitcoin/bitcoin/blob/6c4fe401e908cff1b67d80035b117aae15fe7db
...
📝 fanquake opened a pull request: "Update secp256k1 subtree to latest master "
(https://github.com/bitcoin/bitcoin/pull/33625)
Updates the subtree to https://github.com/bitcoin-core/secp256k1/commit/a44a339384e1e4b1c0ed7fa59e2857b057f075bf.
Related to #33284.
(https://github.com/bitcoin/bitcoin/pull/33625)
Updates the subtree to https://github.com/bitcoin-core/secp256k1/commit/a44a339384e1e4b1c0ed7fa59e2857b057f075bf.
Related to #33284.