💬 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.
💬 Christewart commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3402472699)
As a side note, why was the `generate` command removed from the RPC interface? It seems like this RPC[ could be useful](https://github.com/bitcoin/bitcoin/issues/16000#issuecomment-491486488) and avoid the performance hit of touching the wallet? I'm trying to dig through various PRs and issues and don't see a straight forward answer, perhaps someone knows? #16000 #17700 #19133 #19455
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3402472699)
As a side note, why was the `generate` command removed from the RPC interface? It seems like this RPC[ could be useful](https://github.com/bitcoin/bitcoin/issues/16000#issuecomment-491486488) and avoid the performance hit of touching the wallet? I'm trying to dig through various PRs and issues and don't see a straight forward answer, perhaps someone knows? #16000 #17700 #19133 #19455
💬 maflcko commented on pull request "test: P2SH sig ops are only counted with `SCRIPT_VERIFY_P2SH`":
(https://github.com/bitcoin/bitcoin/pull/33624#issuecomment-3402515314)
review ACK fd2ce880e09c686c320811a322d00b9318f317ae 📌
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK fd2ce880e09c
...
(https://github.com/bitcoin/bitcoin/pull/33624#issuecomment-3402515314)
review ACK fd2ce880e09c686c320811a322d00b9318f317ae 📌
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK fd2ce880e09c
...
💬 achow101 commented on issue "`generatetoaddress` 2-3x slower on v30 compared to v29":
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3402534556)
> As a side note, why was the `generate` command removed from the RPC interface?
Because of the separation between node things and wallet things. `generate` is testing only and there's no good reason to have to add it to the node interface just for a convenience function.
> It seems like this RPChttps://github.com/bitcoin/bitcoin/issues/16000#issuecomment-491486488 and avoid the performance hit of touching the wallet?
It would not make a difference. The behavior is not because of any repeated
...
(https://github.com/bitcoin/bitcoin/issues/33618#issuecomment-3402534556)
> As a side note, why was the `generate` command removed from the RPC interface?
Because of the separation between node things and wallet things. `generate` is testing only and there's no good reason to have to add it to the node interface just for a convenience function.
> It seems like this RPChttps://github.com/bitcoin/bitcoin/issues/16000#issuecomment-491486488 and avoid the performance hit of touching the wallet?
It would not make a difference. The behavior is not because of any repeated
...