š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560753152)
f1cfc07b8af90d9c80c84e9db56d61c56f50d6c2
Are we using this elsewhere or could this be private?
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560753152)
f1cfc07b8af90d9c80c84e9db56d61c56f50d6c2
Are we using this elsewhere or could this be private?
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560767330)
f1cfc07b8af90d9c80c84e9db56d61c56f50d6c2
```Suggestion
// be sure to remove any descendants that are in the pool. This can
```
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560767330)
f1cfc07b8af90d9c80c84e9db56d61c56f50d6c2
```Suggestion
// be sure to remove any descendants that are in the pool. This can
```
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560813764)
05a7b963c93501939ec0523fe0182af87ee40056
not related to cluster mempool, but doesn't this seem pretty expensive, wondering if we can make this an `Assume()` instead
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2560813764)
05a7b963c93501939ec0523fe0182af87ee40056
not related to cluster mempool, but doesn't this seem pretty expensive, wondering if we can make this an `Assume()` instead
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561106726)
d2b0872461158e69675985e8c9e2eb929d904683
seems like these checks are backwards now compared to before, but seems right after these changes...
@glozow ?
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561106726)
d2b0872461158e69675985e8c9e2eb929d904683
seems like these checks are backwards now compared to before, but seems right after these changes...
@glozow ?
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561149521)
c11faf779a1c415f8a04463bfb3febc990eb297b
maybe:
"Transactions submitted to the mempol must not result in clusters which would exceed cluster limits set by"
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561149521)
c11faf779a1c415f8a04463bfb3febc990eb297b
maybe:
"Transactions submitted to the mempol must not result in clusters which would exceed cluster limits set by"
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561313165)
486b441971912bdc63921425d5e40a8c168186ea
pretty sure there's at least one bug here. f.e., if you have three chunks in one cluster, I think the conditional here is only hit the first time, as `current_chunk_feerate` is never reset to the next chunk's size, so it'll just start going negative.
Wrote a test which I think covers it
```
diff --git a/test/functional/mempool_cluster.py b/test/functional/mempool_cluster.py
index 4b4812e619..a7eabef039 100755
--- a/test/functional/mempool_clu
...
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561313165)
486b441971912bdc63921425d5e40a8c168186ea
pretty sure there's at least one bug here. f.e., if you have three chunks in one cluster, I think the conditional here is only hit the first time, as `current_chunk_feerate` is never reset to the next chunk's size, so it'll just start going negative.
Wrote a test which I think covers it
```
diff --git a/test/functional/mempool_cluster.py b/test/functional/mempool_cluster.py
index 4b4812e619..a7eabef039 100755
--- a/test/functional/mempool_clu
...
š¬ instagibbs commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561115129)
ff2a16af040ac0906b4ebd488b1125b6ea25fa14
I don't think we should be tie-breaking based on size here?
```Suggestion
if (chunk_feerate_vsize << m_options.blockMinFeeRate.GetFeePerVSize()) {
```
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2561115129)
ff2a16af040ac0906b4ebd488b1125b6ea25fa14
I don't think we should be tie-breaking based on size here?
```Suggestion
if (chunk_feerate_vsize << m_options.blockMinFeeRate.GetFeePerVSize()) {
```
š¬ TheCharlatan commented on pull request "kernel: Flush in ChainstateManager destructor":
(https://github.com/bitcoin/bitcoin/pull/31382#issuecomment-3577481478)
Re https://github.com/bitcoin/bitcoin/pull/31382#issuecomment-3576740793
> I don't think this is accurate?
Thanks, updated.
(https://github.com/bitcoin/bitcoin/pull/31382#issuecomment-3577481478)
Re https://github.com/bitcoin/bitcoin/pull/31382#issuecomment-3576740793
> I don't think this is accurate?
Thanks, updated.
š¬ TheCharlatan commented on pull request "kernel: Add block header support and validation":
(https://github.com/bitcoin/bitcoin/pull/33822#discussion_r2561338134)
I added a simple headers-first sync mechanism to kernel-ndoe here: https://github.com/TheCharlatan/kernel-node/pull/23
(https://github.com/bitcoin/bitcoin/pull/33822#discussion_r2561338134)
I added a simple headers-first sync mechanism to kernel-ndoe here: https://github.com/TheCharlatan/kernel-node/pull/23
š¬ RandyMcMillan commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3577504127)
š
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3577504127)
š
š¬ RandyMcMillan commented on pull request "chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3577531903)
ACK b0c7067
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3577531903)
ACK b0c7067
š¤ hebasto reviewed a pull request: "depends: latest config.guess & config.sub"
(https://github.com/bitcoin/bitcoin/pull/33945#pullrequestreview-3506757696)
My Guix build:
```
aarch64
50d2ead905b87b4064fd66a0c0a2dc88a7ada65e2224f1ff992bc7ec685e493d guix-build-3e4355314b1a/output/aarch64-linux-gnu/SHA256SUMS.part
923b405f4eb8cb7158f2b4aef0918e48e7e57ef097871d0702dbbd5286013d32 guix-build-3e4355314b1a/output/aarch64-linux-gnu/bitcoin-3e4355314b1a-aarch64-linux-gnu-debug.tar.gz
10317ea4cbaf9b6911592d0d4636d5959bf31f8ad0210cfe8decc4a5ebaa99fb guix-build-3e4355314b1a/output/aarch64-linux-gnu/bitcoin-3e4355314b1a-aarch64-linux-gnu.tar.gz
70bceac6d13861
...
(https://github.com/bitcoin/bitcoin/pull/33945#pullrequestreview-3506757696)
My Guix build:
```
aarch64
50d2ead905b87b4064fd66a0c0a2dc88a7ada65e2224f1ff992bc7ec685e493d guix-build-3e4355314b1a/output/aarch64-linux-gnu/SHA256SUMS.part
923b405f4eb8cb7158f2b4aef0918e48e7e57ef097871d0702dbbd5286013d32 guix-build-3e4355314b1a/output/aarch64-linux-gnu/bitcoin-3e4355314b1a-aarch64-linux-gnu-debug.tar.gz
10317ea4cbaf9b6911592d0d4636d5959bf31f8ad0210cfe8decc4a5ebaa99fb guix-build-3e4355314b1a/output/aarch64-linux-gnu/bitcoin-3e4355314b1a-aarch64-linux-gnu.tar.gz
70bceac6d13861
...
š hebasto approved a pull request: "depends: latest config.guess & config.sub"
(https://github.com/bitcoin/bitcoin/pull/33945#pullrequestreview-3506773750)
ACK 3e4355314b1abf8e4456ea41ba738aaae25abb73, I have reviewed the code and it looks OK.
(https://github.com/bitcoin/bitcoin/pull/33945#pullrequestreview-3506773750)
ACK 3e4355314b1abf8e4456ea41ba738aaae25abb73, I have reviewed the code and it looks OK.
š¬ hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3577653125)
> > Iām unable to reproduce this in a fresh Trixie container using Docker
>
> I did almost the same apart from I checked out this PR rather than building from master.
Sorry. I've adjusted my comment.
> This works on x86 but isn't working on Apple ARM for me.
I can confirm the issue on `aarch64`.
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3577653125)
> > Iām unable to reproduce this in a fresh Trixie container using Docker
>
> I did almost the same apart from I checked out this PR rather than building from master.
Sorry. I've adjusted my comment.
> This works on x86 but isn't working on Apple ARM for me.
I can confirm the issue on `aarch64`.
š¬ lucasbalieiro commented on issue "Memory leak when using IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3577712972)
> [@lucasbalieiro](https://github.com/lucasbalieiro) does Bitcoin Core behave better if you compile the `30.x` branch from source? That's the equivalent of how v30.1 will behave when it comes out.
Built Bitcoin Core at commit **a14e7b9dee9145920f93eab0254ce92942bd1e5e**:
```bash
root@srv-f20833:~/Projects/bitcoin/build/bin# git log
commit a14e7b9dee9145920f93eab0254ce92942bd1e5e (HEAD -> 30.x, origin/30.x)
Merge: d0f6d9953a ae63cc4bf2
Author: merge-script <fanquake@gmail.com>
Date: Thu
```
...
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3577712972)
> [@lucasbalieiro](https://github.com/lucasbalieiro) does Bitcoin Core behave better if you compile the `30.x` branch from source? That's the equivalent of how v30.1 will behave when it comes out.
Built Bitcoin Core at commit **a14e7b9dee9145920f93eab0254ce92942bd1e5e**:
```bash
root@srv-f20833:~/Projects/bitcoin/build/bin# git log
commit a14e7b9dee9145920f93eab0254ce92942bd1e5e (HEAD -> 30.x, origin/30.x)
Merge: d0f6d9953a ae63cc4bf2
Author: merge-script <fanquake@gmail.com>
Date: Thu
```
...
š¬ hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3577726631)
> > This works on x86 but isn't working on Apple ARM for me.
>
> I can confirm the issue on `aarch64`.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121403.
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3577726631)
> > This works on x86 but isn't working on Apple ARM for me.
>
> I can confirm the issue on `aarch64`.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121403.
š¬ diegoviola commented on pull request "Revert "gui, qt: brintToFront workaround for Wayland"":
(https://github.com/bitcoin-core/gui/pull/914#issuecomment-3577784256)
> Built correctly from source both Qt 6.3.2 and 6.10.0, and bringToFront doesn't work on either of them using Wayland.
> 2025-11-25T19:22:58Z System: Ubuntu 22.04.5 LTS, x86_64-little_endian-lp64
That's because Mutter on that GNOME version doesn't support the [XDG activation protocol](https://wayland.app/protocols/xdg-activation-v1). Which is the protocol used by clients to request activation of surfaces.
`GUIUtil::bringToFront` uses `activateWindow()` which uses the XDG activation protoc
...
(https://github.com/bitcoin-core/gui/pull/914#issuecomment-3577784256)
> Built correctly from source both Qt 6.3.2 and 6.10.0, and bringToFront doesn't work on either of them using Wayland.
> 2025-11-25T19:22:58Z System: Ubuntu 22.04.5 LTS, x86_64-little_endian-lp64
That's because Mutter on that GNOME version doesn't support the [XDG activation protocol](https://wayland.app/protocols/xdg-activation-v1). Which is the protocol used by clients to request activation of surfaces.
`GUIUtil::bringToFront` uses `activateWindow()` which uses the XDG activation protoc
...
š¬ AndKe commented on issue "[Linux] Add wayland support":
(https://github.com/bitcoin/bitcoin/issues/19950#issuecomment-3577790159)
even with QT_QPA_PLATFORM=xcb bitcoin-qt is very broken.
Interestingly : bitcoin-25.1 works perfectly fine, 30.0 is very broken on Wayland.
(https://github.com/bitcoin/bitcoin/issues/19950#issuecomment-3577790159)
even with QT_QPA_PLATFORM=xcb bitcoin-qt is very broken.
Interestingly : bitcoin-25.1 works perfectly fine, 30.0 is very broken on Wayland.
š hodlinator approved a pull request: "refactor, docs: Embedded ASMap [2/3]: Refactor asmap internals and add documentation"
(https://github.com/bitcoin/bitcoin/pull/33878#pullrequestreview-3503770177)
ACK 825d677a863d153d4c466288397da773ee2bb2f5
Operating on `std::span<std::byte>` rather than `std::vector<bool>&` enables for efficient use of asmap data embedded in the binary (#28792).
I have thoroughly reviewed and contributed patches for this refactoring up to the point of having a conflict of interest in getting it merged. :)
To build more confidence of the `bool` -> `byte` transition, I developed a C++ test with more readable asmap input data - cf34bb9806e95116d4b65b6dc80dc11a1f723a51 (
...
(https://github.com/bitcoin/bitcoin/pull/33878#pullrequestreview-3503770177)
ACK 825d677a863d153d4c466288397da773ee2bb2f5
Operating on `std::span<std::byte>` rather than `std::vector<bool>&` enables for efficient use of asmap data embedded in the binary (#28792).
I have thoroughly reviewed and contributed patches for this refactoring up to the point of having a conflict of interest in getting it merged. :)
To build more confidence of the `bool` -> `byte` transition, I developed a C++ test with more readable asmap input data - cf34bb9806e95116d4b65b6dc80dc11a1f723a51 (
...
š¬ hodlinator commented on pull request "refactor, docs: Embedded ASMap [2/3]: Refactor asmap internals and add documentation":
(https://github.com/bitcoin/bitcoin/pull/33878#discussion_r2558964758)
Ah, makes sense too. :+1:
(https://github.com/bitcoin/bitcoin/pull/33878#discussion_r2558964758)
Ah, makes sense too. :+1: