💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417959306)
This is now dealt with more consistently in a new commit that introduces a range of valid transaction counts for each `Cluster` implementation.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417959306)
This is now dealt with more consistently in a new commit that introduces a range of valid transaction counts for each `Cluster` implementation.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961019)
Why not both?
They're independent notions: one is a policy-configurable per-TxGraph maximum cluster count, and the other is a Cluster-implementation dependent limit.
Done.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961019)
Why not both?
They're independent notions: one is a policy-configurable per-TxGraph maximum cluster count, and the other is a Cluster-implementation dependent limit.
Done.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961661)
Right.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961661)
Right.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961927)
Done.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417961927)
Done.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417962125)
Fixed.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417962125)
Fixed.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417962445)
Good idea, done.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417962445)
Good idea, done.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417963146)
Fair point, done.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417963146)
Fair point, done.
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417964329)
Indeed. Changed into an `assert(false);`, plus a comment explaining why, and a `SingletonClusterImpl::SanityCheck()` check to verify that claim.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2417964329)
Indeed. Changed into an `assert(false);`, plus a comment explaining why, and a `SingletonClusterImpl::SanityCheck()` check to verify that claim.
📝 amishhaa opened a pull request: "Contrib: Updated macdeployqtplus to remove deprecated --deep signing"
(https://github.com/bitcoin/bitcoin/pull/33592)
**Description**
Removed the deprecated --deep flag from codesign in macdeployqtplus and replaced it with an explicit recursive signing process for all binaries, frameworks, and plugins.
Fixes #32486
<img width="624" height="370" alt="Screenshot 2025-10-10 at 2 36 16 AM" src="https://github.com/user-attachments/assets/6329b67e-e400-4d8d-947c-25bceab4cb55" />
**Steps To Reproduce**
N/A since not a bug only deprecating an arg
**Steps To Test**
- Set up the app normally.
- Signing w
...
(https://github.com/bitcoin/bitcoin/pull/33592)
**Description**
Removed the deprecated --deep flag from codesign in macdeployqtplus and replaced it with an explicit recursive signing process for all binaries, frameworks, and plugins.
Fixes #32486
<img width="624" height="370" alt="Screenshot 2025-10-10 at 2 36 16 AM" src="https://github.com/user-attachments/assets/6329b67e-e400-4d8d-947c-25bceab4cb55" />
**Steps To Reproduce**
N/A since not a bug only deprecating an arg
**Steps To Test**
- Set up the app normally.
- Signing w
...
📝 hebasto opened a pull request: "guix: Use UCRT runtime for Windows release binaries"
(https://github.com/bitcoin/bitcoin/pull/33593)
This PR switches Windows release binaries to UCRT and resolves one item from https://github.com/bitcoin/bitcoin/issues/30210:
- [x] A symbol-check that the new runtime is indeed being used.
Guix builds on both `x86_64` and `aarch64` platforms:
```
b8df1d6c3bf2a4342aa19385444b221503eec2faed8656645e656fc60c1563a0 guix-build-f380e6251021/output/dist-archive/bitcoin-f380e6251021.tar.gz
3c57789c22a0670b1395f25bab2b5951d58b3cef57d33d48c93b1f51b0ca21d9 guix-build-f380e6251021/output/x86_64-w64
...
(https://github.com/bitcoin/bitcoin/pull/33593)
This PR switches Windows release binaries to UCRT and resolves one item from https://github.com/bitcoin/bitcoin/issues/30210:
- [x] A symbol-check that the new runtime is indeed being used.
Guix builds on both `x86_64` and `aarch64` platforms:
```
b8df1d6c3bf2a4342aa19385444b221503eec2faed8656645e656fc60c1563a0 guix-build-f380e6251021/output/dist-archive/bitcoin-f380e6251021.tar.gz
3c57789c22a0670b1395f25bab2b5951d58b3cef57d33d48c93b1f51b0ca21d9 guix-build-f380e6251021/output/x86_64-w64
...
💬 mzumsande commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2418065022)
I like the suggested approach, it is alos much than a multi-step approach, so I changed to it.
> If performance of LastCommonAncestor is a concern
I don't think so, in particular because it replaces the long-existing `LastCommonAncestor(state->pindexLastCommonBlock, state->pindexBestKnownBlock);` call which should be of very similar duration (during IBD, the old `pindexLastCommonBlock` is close to the current tip, while `pindexBestKnownBlock` is at the best known header typically.
> I g
...
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2418065022)
I like the suggested approach, it is alos much than a multi-step approach, so I changed to it.
> If performance of LastCommonAncestor is a concern
I don't think so, in particular because it replaces the long-existing `LastCommonAncestor(state->pindexLastCommonBlock, state->pindexBestKnownBlock);` call which should be of very similar duration (during IBD, the old `pindexLastCommonBlock` is close to the current tip, while `pindexBestKnownBlock` is at the best known header typically.
> I g
...
💬 mzumsande commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3387634625)
[b2c6cb7](https://github.com/bitcoin/bitcoin/commit/b2c6cb7f026ff704c227e632f8c5c2f09e6f058a) to [01cc20f](https://github.com/bitcoin/bitcoin/commit/01cc20f3307c532f402cdf5dc17f2f14920b725b): changed the approach of the main commit to the suggestion by @sipa. I also added a comment and rewrote the commit message.
(https://github.com/bitcoin/bitcoin/pull/32180#issuecomment-3387634625)
[b2c6cb7](https://github.com/bitcoin/bitcoin/commit/b2c6cb7f026ff704c227e632f8c5c2f09e6f058a) to [01cc20f](https://github.com/bitcoin/bitcoin/commit/01cc20f3307c532f402cdf5dc17f2f14920b725b): changed the approach of the main commit to the suggestion by @sipa. I also added a comment and rewrote the commit message.
📝 abishek003-tech opened a pull request: "mzumsande"
(https://github.com/bitcoin/bitcoin/pull/33594)
Title:
Avoid using invalidateblock to directly test reorg behavior
Summary:
This update replaces direct invalidateblock-based reorg simulations in functional tests with a proper fork-based reorg approach.
Using invalidateblock alone to trigger reorgs causes unrealistic behavior, such as:
Limited reorg depth (only up to 10 blocks re-entering the mempool)
Incorrect descendant chain validation (PreChecks not executed per reorg)
Divergent code path compared to real-world Bitcoin reorg
...
(https://github.com/bitcoin/bitcoin/pull/33594)
Title:
Avoid using invalidateblock to directly test reorg behavior
Summary:
This update replaces direct invalidateblock-based reorg simulations in functional tests with a proper fork-based reorg approach.
Using invalidateblock alone to trigger reorgs causes unrealistic behavior, such as:
Limited reorg depth (only up to 10 blocks re-entering the mempool)
Incorrect descendant chain validation (PreChecks not executed per reorg)
Divergent code path compared to real-world Bitcoin reorg
...
✅ fanquake closed a pull request: "mzumsande"
(https://github.com/bitcoin/bitcoin/pull/33594)
(https://github.com/bitcoin/bitcoin/pull/33594)
👍 l0rinc approved a pull request: "build: Bump clang minimum supported version to 17"
(https://github.com/bitcoin/bitcoin/pull/33555#pullrequestreview-3320830812)
Code review ACK fa0fa0f70087d08fe5a54832b96799bd14293279
(https://github.com/bitcoin/bitcoin/pull/33555#pullrequestreview-3320830812)
Code review ACK fa0fa0f70087d08fe5a54832b96799bd14293279
⚠️ jotapea opened an issue: "Decouple Datacarrier Size and Nulldata Output Limits"
(https://github.com/bitcoin/bitcoin/issues/33595)
# DRAFT: PR #X Decouple Datacarrier Size and Nulldata Output Limits for Granular OP_RETURN Policy
Status: Draft | Target: Bitcoin Core v30.1 (Q4 2025) | Author: @jotapea
## Motivation
With Bitcoin Core v30, support for multiple OP_RETURN outputs has been introduced, allowing up to 100,000 bytes in total.
This change aligns with miner incentives to accept data storage use, while enhancing Bitcoin's "censorship resistance". This is social debate, and out of the scope of this PR.
However, v30'
...
(https://github.com/bitcoin/bitcoin/issues/33595)
# DRAFT: PR #X Decouple Datacarrier Size and Nulldata Output Limits for Granular OP_RETURN Policy
Status: Draft | Target: Bitcoin Core v30.1 (Q4 2025) | Author: @jotapea
## Motivation
With Bitcoin Core v30, support for multiple OP_RETURN outputs has been introduced, allowing up to 100,000 bytes in total.
This change aligns with miner incentives to accept data storage use, while enhancing Bitcoin's "censorship resistance". This is social debate, and out of the scope of this PR.
However, v30'
...
📝 Ashok-0167 opened a pull request: "Add warning and documentation for -bind with Tor hidden services (#33…"
(https://github.com/bitcoin/bitcoin/pull/33596)
…458)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests th
...
(https://github.com/bitcoin/bitcoin/pull/33596)
…458)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests th
...
💬 pinheadmz commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387847521)
concept NACK, I don't think this extra configuration complexity adds anything useful to the software or the network as a whole. Miners are already including transactions without restriction on size, which is the whole reason why #32406 was proposed, discussed, written, reviewed, and merged.
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387847521)
concept NACK, I don't think this extra configuration complexity adds anything useful to the software or the network as a whole. Miners are already including transactions without restriction on size, which is the whole reason why #32406 was proposed, discussed, written, reviewed, and merged.
💬 w0xlt commented on pull request "coins: fix `cachedCoinsUsage` accounting in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2418231037)
If `inserted=false`, you've still moved from `coin`.
Is this expected behavior ?
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2418231037)
If `inserted=false`, you've still moved from `coin`.
Is this expected behavior ?
💬 l0rinc commented on pull request "[30.x] Finalise v30.0":
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3387858376)
I ran a full `-reindex` with v30.0 (d5e0077bef4cc4484242bb9a88a4840bc803c091) until current tip (`height=918366`) with default `dbcache` (=450 MB) and fully enabled script validation (`-assumevalid=0`): it finished successfully in **11 hours, 22 minutes**.
Post-merge ACK
(https://github.com/bitcoin/bitcoin/pull/33559#issuecomment-3387858376)
I ran a full `-reindex` with v30.0 (d5e0077bef4cc4484242bb9a88a4840bc803c091) until current tip (`height=918366`) with default `dbcache` (=450 MB) and fully enabled script validation (`-assumevalid=0`): it finished successfully in **11 hours, 22 minutes**.
Post-merge ACK