📝 hebasto opened a pull request: "doc: Correct `pkgin` command usage on NetBSD"
(https://github.com/bitcoin/bitcoin/pull/33827)
When using `pkgin` on NetBSD, the `install` command must be specified.
(https://github.com/bitcoin/bitcoin/pull/33827)
When using `pkgin` on NetBSD, the `install` command must be specified.
💬 TheCharlatan commented on pull request "ci: Enable experimental kernel stuff in most CI tasks":
(https://github.com/bitcoin/bitcoin/pull/33824#issuecomment-3506817226)
Thanks for going through this!
My guess is the failure in the previous releases job is gcc11's limited implementation of std::ranges. Not sure what to do about that to be honest. Maybe we can add a macro guard for those test cases?
The test case producing the ubsan error should just be deleted in my opinion. It does not add anything in terms of coverage. How about:
```diff
diff --git a/src/test/kernel/test_kernel.cpp b/src/test/kernel/test_kernel.cpp
index d9875ee16e..b170ea182d 100644
...
(https://github.com/bitcoin/bitcoin/pull/33824#issuecomment-3506817226)
Thanks for going through this!
My guess is the failure in the previous releases job is gcc11's limited implementation of std::ranges. Not sure what to do about that to be honest. Maybe we can add a macro guard for those test cases?
The test case producing the ubsan error should just be deleted in my opinion. It does not add anything in terms of coverage. How about:
```diff
diff --git a/src/test/kernel/test_kernel.cpp b/src/test/kernel/test_kernel.cpp
index d9875ee16e..b170ea182d 100644
...
💬 l0rinc commented on issue "malloc: Failed to allocate segment from range group - out of space":
(https://github.com/bitcoin/bitcoin/issues/33806#issuecomment-3506817713)
So it seems that v26 handles these smoothly without an OOM, but v27-30 OOMs for dbcache sizes >8.7GB on Mac. So it also crashes for a 10 GB dbcache on a 64GB system.
Can somebody else reproduce this?
I suspect it may be related to https://github.com/bitcoin/bitcoin/pull/25325.
----
I have instrumented the `UpdateTip` messages with dbcache `buckets` and system free memory - to plot the behavior before the crash, so the entries look like:
```
2025-11-08T19:07:15Z UpdateTip: new best=000000000000
...
(https://github.com/bitcoin/bitcoin/issues/33806#issuecomment-3506817713)
So it seems that v26 handles these smoothly without an OOM, but v27-30 OOMs for dbcache sizes >8.7GB on Mac. So it also crashes for a 10 GB dbcache on a 64GB system.
Can somebody else reproduce this?
I suspect it may be related to https://github.com/bitcoin/bitcoin/pull/25325.
----
I have instrumented the `UpdateTip` messages with dbcache `buckets` and system free memory - to plot the behavior before the crash, so the entries look like:
```
2025-11-08T19:07:15Z UpdateTip: new best=000000000000
...
💬 151henry151 commented on pull request "build: Remove CMAKE_SKIP_BUILD_RPATH and SKIP_BUILD_RPATH settings":
(https://github.com/bitcoin/bitcoin/pull/33247#issuecomment-3506863352)
> Could you please also remove the workaround for NetBSD by reverting commit [11115e9](https://github.com/bitcoin/bitcoin/commit/11115e9aa845d675a88e18e729913f0aaa11e322)?
I think I've made the correct change; however I made a couple clumsy mistakes on the way -- tried to clean up the mess so the commit history looks clean and tidy -- let me know if there's anything further I should do here. I don't have an environment set up to test building for NetBSD, and if I'm not mistaken, this shouldn'
...
(https://github.com/bitcoin/bitcoin/pull/33247#issuecomment-3506863352)
> Could you please also remove the workaround for NetBSD by reverting commit [11115e9](https://github.com/bitcoin/bitcoin/commit/11115e9aa845d675a88e18e729913f0aaa11e322)?
I think I've made the correct change; however I made a couple clumsy mistakes on the way -- tried to clean up the mess so the commit history looks clean and tidy -- let me know if there's anything further I should do here. I don't have an environment set up to test building for NetBSD, and if I'm not mistaken, this shouldn'
...
💬 ajtowns commented on pull request "build: add `-W*-whitespace`":
(https://github.com/bitcoin/bitcoin/pull/32482#issuecomment-3506876620)
Concept ACK. The large commits here should be scripted-diffs though. I believe the following works, if expand/sponge are available:
```
scripted-diff: univalue: change leading whitespace to spaces
-BEGIN VERIFY SCRIPT-
sed -i 's/^\t/ /' src/univalue/include/univalue_escapes.h
-END VERIFY SCRIPT-
```
```
scripted-diff: crypto: remove tabs and trailing whitespace in sha256_sse4.cpp
-BEGIN VERIFY SCRIPT-
expand -t4 src/crypto/sha256_sse4.cpp | sed 's/ *$//' | sponge src/crypto
...
(https://github.com/bitcoin/bitcoin/pull/32482#issuecomment-3506876620)
Concept ACK. The large commits here should be scripted-diffs though. I believe the following works, if expand/sponge are available:
```
scripted-diff: univalue: change leading whitespace to spaces
-BEGIN VERIFY SCRIPT-
sed -i 's/^\t/ /' src/univalue/include/univalue_escapes.h
-END VERIFY SCRIPT-
```
```
scripted-diff: crypto: remove tabs and trailing whitespace in sha256_sse4.cpp
-BEGIN VERIFY SCRIPT-
expand -t4 src/crypto/sha256_sse4.cpp | sed 's/ *$//' | sponge src/crypto
...
📝 151henry151 opened a pull request: "Check required interfaces before generating manpages"
(https://github.com/bitcoin/bitcoin/pull/33828)
Guard manpage generation by reading CMakeCache.txt and exiting if HAVE_SYSTEM, ENABLE_WALLET, or WITH_ZMQ are off, and provide a short hint so contributors rebuild with the right flags instead of committing incomplete manpages.
Fixes #17506
(https://github.com/bitcoin/bitcoin/pull/33828)
Guard manpage generation by reading CMakeCache.txt and exiting if HAVE_SYSTEM, ENABLE_WALLET, or WITH_ZMQ are off, and provide a short hint so contributors rebuild with the right flags instead of committing incomplete manpages.
Fixes #17506
💬 ajtowns commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3506898619)
> FYI for reviewers: the insertion of the `AssertLockHeld()` in txmempool.h in that commit is what made the bug easy to reproduce in our tests (using a debug build).
AIUI, constructors and destructors ignore lock annotations `~ChangeSet() EXCLUSIVE_LOCKS_REQUIRED(m_pool->cs) { AssertLockHeld(m_pool->cs);` -- so a runtime assertion makes sense. (Short of changing the thread safety model entirely, I guess)
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3506898619)
> FYI for reviewers: the insertion of the `AssertLockHeld()` in txmempool.h in that commit is what made the bug easy to reproduce in our tests (using a debug build).
AIUI, constructors and destructors ignore lock annotations `~ChangeSet() EXCLUSIVE_LOCKS_REQUIRED(m_pool->cs) { AssertLockHeld(m_pool->cs);` -- so a runtime assertion makes sense. (Short of changing the thread safety model entirely, I guess)
🤔 TheCharlatan reviewed a pull request: "kernel: trim Chain interface"
(https://github.com/bitcoin/bitcoin/pull/33820#pullrequestreview-3438917702)
Concept ACK
These were introduced before we had a dedicated iterator for traversing the chain. At this point, their benefit (thread safety) is kind of marginal.
(https://github.com/bitcoin/bitcoin/pull/33820#pullrequestreview-3438917702)
Concept ACK
These were introduced before we had a dedicated iterator for traversing the chain. At this point, their benefit (thread safety) is kind of marginal.
💬 TheCharlatan commented on pull request "kernel: trim Chain interface":
(https://github.com/bitcoin/bitcoin/pull/33820#discussion_r2507308573)
I wonder if we should even keep these methods now. The previous calls to tip and genesis were at least thread safe (which these are no longer). I agree that it is not worth keeping them just for the sake of it, but also not sure if they still provide utility here.
(https://github.com/bitcoin/bitcoin/pull/33820#discussion_r2507308573)
I wonder if we should even keep these methods now. The previous calls to tip and genesis were at least thread safe (which these are no longer). I agree that it is not worth keeping them just for the sake of it, but also not sure if they still provide utility here.
💬 brunoerg commented on issue "Fuzz: compare our AES implementation to AES-NI ":
(https://github.com/bitcoin/bitcoin/issues/27548#issuecomment-3507064396)
> @brunoerg perhaps something to add to bitcoinfuzz? Otherwise if cryptofuzz gets revived, that might also be something (if it wasn't already in there).
Since cryptofuzz is not alive anymore, we could have it on bitcoinfuzz. I will open an issue there.
(https://github.com/bitcoin/bitcoin/issues/27548#issuecomment-3507064396)
> @brunoerg perhaps something to add to bitcoinfuzz? Otherwise if cryptofuzz gets revived, that might also be something (if it wasn't already in there).
Since cryptofuzz is not alive anymore, we could have it on bitcoinfuzz. I will open an issue there.
⚠️ vortexowll opened an issue: "Submission of a Historical & Experiential Report on the Creation of Bitcoin — Request for Dialogue"
(https://github.com/bitcoin/bitcoin/issues/33829)
Hello Bitcoin Core contributors and community,
My name is Richard Krause. I’ve prepared a detailed document that combines a historical overview of the birth of Bitcoin and my firsthand account of parallel spiritual and computational frameworks of decentralization, sovereignty, energy circulation, and value.
The document is titled “Parallel Origins: A Personal Reflection on the Creation of Bitcoin and the Hidden Architecture of Energy and Trust.” It explores the overlap between technological i
...
(https://github.com/bitcoin/bitcoin/issues/33829)
Hello Bitcoin Core contributors and community,
My name is Richard Krause. I’ve prepared a detailed document that combines a historical overview of the birth of Bitcoin and my firsthand account of parallel spiritual and computational frameworks of decentralization, sovereignty, energy circulation, and value.
The document is titled “Parallel Origins: A Personal Reflection on the Creation of Bitcoin and the Hidden Architecture of Energy and Trust.” It explores the overlap between technological i
...
✅ pinheadmz closed an issue: "Submission of a Historical & Experiential Report on the Creation of Bitcoin — Request for Dialogue"
(https://github.com/bitcoin/bitcoin/issues/33829)
(https://github.com/bitcoin/bitcoin/issues/33829)
💬 pinheadmz commented on issue "Submission of a Historical & Experiential Report on the Creation of Bitcoin — Request for Dialogue":
(https://github.com/bitcoin/bitcoin/issues/33829#issuecomment-3507132268)
This should be posted on the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev), the [Delving Bitcoin forum](https://delvingbitcoin.org/) or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on [Stack Exchange](https://bitcoin.stackexchange.com/). The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.
(https://github.com/bitcoin/bitcoin/issues/33829#issuecomment-3507132268)
This should be posted on the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev), the [Delving Bitcoin forum](https://delvingbitcoin.org/) or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on [Stack Exchange](https://bitcoin.stackexchange.com/). The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.
🤔 sfgroupltd78-gif reviewed a pull request: "refactor: Add missing include in bitcoinkernel_wrapper.h"
(https://github.com/bitcoin/bitcoin/pull/33825#pullrequestreview-3439072081)
with the pull request files athttps:
(https://github.com/bitcoin/bitcoin/pull/33825#pullrequestreview-3439072081)
with the pull request files athttps:
💬 sfgroupltd78-gif commented on pull request "refactor: Add missing include in bitcoinkernel_wrapper.h":
(https://github.com/bitcoin/bitcoin/pull/33825#issuecomment-3507272109)
Fan
(https://github.com/bitcoin/bitcoin/pull/33825#issuecomment-3507272109)
Fan
📝 lancemitchell157-maker opened a pull request: "Create devcontainer.json"
(https://github.com/bitcoin/bitcoin/pull/33830)
<!--
*** 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 that improv
...
(https://github.com/bitcoin/bitcoin/pull/33830)
<!--
*** 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 that improv
...
📝 lancemitchell157-maker opened a pull request: "Create devcontainer.json"
(https://github.com/bitcoin/bitcoin/pull/33831)
<!--
*** 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 that improv
...
(https://github.com/bitcoin/bitcoin/pull/33831)
<!--
*** 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 that improv
...
💬 waketraindev commented on issue "Cache headers in REST":
(https://github.com/bitcoin/bitcoin/issues/33809#issuecomment-3507829348)
Cache-Control headers can be easily handled at the nginx layer. Rather than adding this logic directly in Bitcoin REST code, it might make sense to include a sample nginx config under contrib/ with reasonable defaults for REST endpoints.
```
# Example include: rest-cache.conf
location /rest/block/ {
# Cache block lookups by hash for a long time (immutable)
if ($uri ~ "^/rest/block/[0-9a-f]+\.json$") {
add_header Cache-Control "public, max-age=31536000, immutable";
}
# C
...
(https://github.com/bitcoin/bitcoin/issues/33809#issuecomment-3507829348)
Cache-Control headers can be easily handled at the nginx layer. Rather than adding this logic directly in Bitcoin REST code, it might make sense to include a sample nginx config under contrib/ with reasonable defaults for REST endpoints.
```
# Example include: rest-cache.conf
location /rest/block/ {
# Cache block lookups by hash for a long time (immutable)
if ($uri ~ "^/rest/block/[0-9a-f]+\.json$") {
add_header Cache-Control "public, max-age=31536000, immutable";
}
# C
...
💬 yancyribbens commented on pull request "docs: add doc comment for SRD selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/33622#discussion_r2507900417)
I think I see now what you are getting on when you say "Budgeting separately". You're saying that by budgeting separately you are providing a value to be used for change_fee and any value used for change fee will be at least `CHANGE_LOWER`. If there is no other discussion on this i'll accept it and move on, but this is pretty confusing imo. It also doesn't make clear that you can just not "budget separately" and the change_fee will be equal to `CHANGE_LOWER`.
(https://github.com/bitcoin/bitcoin/pull/33622#discussion_r2507900417)
I think I see now what you are getting on when you say "Budgeting separately". You're saying that by budgeting separately you are providing a value to be used for change_fee and any value used for change fee will be at least `CHANGE_LOWER`. If there is no other discussion on this i'll accept it and move on, but this is pretty confusing imo. It also doesn't make clear that you can just not "budget separately" and the change_fee will be equal to `CHANGE_LOWER`.
💬 yancyribbens commented on pull request "docs: add doc comment for SRD selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/33622#discussion_r2507913429)
I think ideally a default parameter value is used here: `CAmount change_fee = CHANGE_LOWER`. That way it's made more clear that either you budget separately for the `change_fee` or it will default to CHANGE_LOWER. In most cases CHANGE_LOWER should be plenty for a change_fee.
(https://github.com/bitcoin/bitcoin/pull/33622#discussion_r2507913429)
I think ideally a default parameter value is used here: `CAmount change_fee = CHANGE_LOWER`. That way it's made more clear that either you budget separately for the `change_fee` or it will default to CHANGE_LOWER. In most cases CHANGE_LOWER should be plenty for a change_fee.