💬 Sjors commented on pull request "multiprocess: Fix high overhead from message logging":
(https://github.com/bitcoin/bitcoin/pull/33517#issuecomment-3400641744)
ACK 0626b90f507db68610a69feec86deb712dd095a1
(https://github.com/bitcoin/bitcoin/pull/33517#issuecomment-3400641744)
ACK 0626b90f507db68610a69feec86deb712dd095a1
💬 maflcko commented on pull request "ci: Build ci_native_base image layer":
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400671936)
Also, it won't work anyway, due to `--cache-to`: https://github.com/maflcko/bitcoin-core-with-ci/actions/runs/18490105374/job/52681542962#step:6:149:
```
+ docker buildx ls --format '{{.DriverEndpoint}} {{.Name}}'
Using existing docker based buildx: default
Building ci_native_base image layer
+ docker buildx build --file=/home/runner/work/bitcoin-core-with-ci/bitcoin-core-with-ci/ci/test_imagefile_base --platform=linux --label=bitcoin-ci-test --tag=ci_native_base --cache-from type=gha,sco
...
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400671936)
Also, it won't work anyway, due to `--cache-to`: https://github.com/maflcko/bitcoin-core-with-ci/actions/runs/18490105374/job/52681542962#step:6:149:
```
+ docker buildx ls --format '{{.DriverEndpoint}} {{.Name}}'
Using existing docker based buildx: default
Building ci_native_base image layer
+ docker buildx build --file=/home/runner/work/bitcoin-core-with-ci/bitcoin-core-with-ci/ci/test_imagefile_base --platform=linux --label=bitcoin-ci-test --tag=ci_native_base --cache-from type=gha,sco
...
💬 Raimo33 commented on pull request "p2p: Allow block downloads from peers without snapshot block after assumeutxo validation":
(https://github.com/bitcoin/bitcoin/pull/33604#issuecomment-3400714807)
Concept ACK
approach seems fine
(https://github.com/bitcoin/bitcoin/pull/33604#issuecomment-3400714807)
Concept ACK
approach seems fine
💬 Raimo33 commented on pull request "node: change a tx-relay on/off flag to enum":
(https://github.com/bitcoin/bitcoin/pull/33567#issuecomment-3400743635)
Concept NACK.
what would be a third option? it's either relay or not.
(https://github.com/bitcoin/bitcoin/pull/33567#issuecomment-3400743635)
Concept NACK.
what would be a third option? it's either relay or not.
👍 hodlinator approved a pull request: "ci: Add macOS cross task for arm64-apple-darwin"
(https://github.com/bitcoin/bitcoin/pull/33549#pullrequestreview-3334496537)
crACK fad5a7101cc3dccbb525cfe9afc105aace8da88e
(https://github.com/bitcoin/bitcoin/pull/33549#pullrequestreview-3334496537)
crACK fad5a7101cc3dccbb525cfe9afc105aace8da88e
💬 hodlinator commented on pull request "ci: Add macOS cross task for arm64-apple-darwin":
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428354982)
nits in fa8c750a0aff9c03270b71a91536639f3922eed8:
Can't see any reference in the configs/scripts for how this step is reused for Mac. Maybe there's some part of the Cirrus config I'm not finding, although I can't see it being run in the logs either (https://productionresultssa9.blob.core.windows.net/actions-results/b7d9a1c2-e433-4d61-91b6-663cde22c2f6/workflow-job-run-8d60d8fe-2ef0-566b-bad9-1d540924800c/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-10-14T09%3A00%3A24Z&sig=F60Lcc0LkB2xmwQ8QEI
...
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428354982)
nits in fa8c750a0aff9c03270b71a91536639f3922eed8:
Can't see any reference in the configs/scripts for how this step is reused for Mac. Maybe there's some part of the Cirrus config I'm not finding, although I can't see it being run in the logs either (https://productionresultssa9.blob.core.windows.net/actions-results/b7d9a1c2-e433-4d61-91b6-663cde22c2f6/workflow-job-run-8d60d8fe-2ef0-566b-bad9-1d540924800c/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-10-14T09%3A00%3A24Z&sig=F60Lcc0LkB2xmwQ8QEI
...
💬 hodlinator commented on pull request "ci: Add macOS cross task for arm64-apple-darwin":
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428360859)
reviewed: Diffed against ci/test/00_setup_env_mac_cross.sh and only `CONTAINER_NAME` & `HOST` differ by CPU-arch, as expected.
Makes sense to have ARM be the main one going forward and move the old setup to "_intel".
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428360859)
reviewed: Diffed against ci/test/00_setup_env_mac_cross.sh and only `CONTAINER_NAME` & `HOST` differ by CPU-arch, as expected.
Makes sense to have ARM be the main one going forward and move the old setup to "_intel".
🚀 fanquake merged a pull request: "ci: fix buildx gha cache authentication on forks"
(https://github.com/bitcoin/bitcoin/pull/33508)
(https://github.com/bitcoin/bitcoin/pull/33508)
💬 fanquake commented on pull request "ci: fix buildx gha cache authentication on forks":
(https://github.com/bitcoin/bitcoin/pull/33508#issuecomment-3400800275)
Backported to `30.x` in #33609.
(https://github.com/bitcoin/bitcoin/pull/33508#issuecomment-3400800275)
Backported to `30.x` in #33609.
💬 maflcko commented on pull request "ci: Add macOS cross task for arm64-apple-darwin":
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428422264)
It is not used right now, but can be in the future. This is a separate commit. I'll adjust the commit message the next time I have to re-touch to clarify this further.
(https://github.com/bitcoin/bitcoin/pull/33549#discussion_r2428422264)
It is not used right now, but can be in the future. This is a separate commit. I'll adjust the commit message the next time I have to re-touch to clarify this further.
💬 fanquake commented on pull request "ci: fix buildx gha cache authentication on forks":
(https://github.com/bitcoin/bitcoin/pull/33508#issuecomment-3400827432)
Backported to `29.x` in #33611.
(https://github.com/bitcoin/bitcoin/pull/33508#issuecomment-3400827432)
Backported to `29.x` in #33611.
💬 willcl-ark commented on pull request "ci: Build ci_native_base image layer":
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400842646)
I think if we want something like this to work it could be tricky without using a registry to host the base image which all other jobs pulled from (on a cache hit).
It may be possible without one, but as each job is `scope`d to itself, which is what keeps the caches seperate,: https://github.com/bitcoin/bitcoin/actions/runs/18489967967/job/52681101678?pr=33620#step:9:151 ... I think current approach would end up with one base_image per job, which is not quite what we are after here.
One po
...
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400842646)
I think if we want something like this to work it could be tricky without using a registry to host the base image which all other jobs pulled from (on a cache hit).
It may be possible without one, but as each job is `scope`d to itself, which is what keeps the caches seperate,: https://github.com/bitcoin/bitcoin/actions/runs/18489967967/job/52681101678?pr=33620#step:9:151 ... I think current approach would end up with one base_image per job, which is not quite what we are after here.
One po
...
💬 optout21 commented on pull request "net_processing: rename RelayTransaction to better describe what it does":
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2428458168)
There have been several valid points mentioned about naming:
- it doesn't really broadcast, just initiates the broadcast process
- 'schedule' suggest scheduling at a given future time
- 'queue' suggests placing in some concrete queue
I can also add one:
- for the a user of this method, the intent is to _broadcast_, the other details are secondary
I can also propose some more alternatives:
- `InitiateTxBroadcastToAll()`
- `EnqueueTxForBroadcastToAll()`
- `BackgroundBroadcastTxToAll
...
(https://github.com/bitcoin/bitcoin/pull/33565#discussion_r2428458168)
There have been several valid points mentioned about naming:
- it doesn't really broadcast, just initiates the broadcast process
- 'schedule' suggest scheduling at a given future time
- 'queue' suggests placing in some concrete queue
I can also add one:
- for the a user of this method, the intent is to _broadcast_, the other details are secondary
I can also propose some more alternatives:
- `InitiateTxBroadcastToAll()`
- `EnqueueTxForBroadcastToAll()`
- `BackgroundBroadcastTxToAll
...
💬 optout21 commented on pull request "node: change a tx-relay on/off flag to enum":
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2428501514)
For better readability, I suggest deciding upfront if mempool-adding and relaying is required respectively, and working accordingly. This avoids repeating `case` statements.
In fact this logic (for a certain enum option mempool-adding/relaying is needed) could go as a method into the enum.
```diff
diff --git a/src/node/transaction.cpp b/src/node/transaction.cpp
index 5da4e878ab..e2d0ba76e2 100644
--- a/src/node/transaction.cpp
+++ b/src/node/transaction.cpp
@@ -49,6 +49,18 @@ TransactionError B
...
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2428501514)
For better readability, I suggest deciding upfront if mempool-adding and relaying is required respectively, and working accordingly. This avoids repeating `case` statements.
In fact this logic (for a certain enum option mempool-adding/relaying is needed) could go as a method into the enum.
```diff
diff --git a/src/node/transaction.cpp b/src/node/transaction.cpp
index 5da4e878ab..e2d0ba76e2 100644
--- a/src/node/transaction.cpp
+++ b/src/node/transaction.cpp
@@ -49,6 +49,18 @@ TransactionError B
...
✅ willcl-ark closed an issue: "Revert OP_RETURN Policy Changes in Bitcoin Core v0.30"
(https://github.com/bitcoin/bitcoin/issues/33619)
(https://github.com/bitcoin/bitcoin/issues/33619)
💬 willcl-ark commented on issue "Revert OP_RETURN Policy Changes in Bitcoin Core v0.30":
(https://github.com/bitcoin/bitcoin/issues/33619#issuecomment-3400930073)
Hello @besoeasy I'm going to close this as I don't think that the issue tracker in this repo is the place for this type of discussion at this point: this has already been hashed out in various technical PRs in this repo, as well as on other social forums for multiple years now.
Bitcoin Core v30.0 still includes the `-datacarriersize` command line flag which you can set to `83` to get ~ the same configuration as a pre-v30.0 node (although it will permit multiple smaller `OP_RETURN`s up to the to
...
(https://github.com/bitcoin/bitcoin/issues/33619#issuecomment-3400930073)
Hello @besoeasy I'm going to close this as I don't think that the issue tracker in this repo is the place for this type of discussion at this point: this has already been hashed out in various technical PRs in this repo, as well as on other social forums for multiple years now.
Bitcoin Core v30.0 still includes the `-datacarriersize` command line flag which you can set to `83` to get ~ the same configuration as a pre-v30.0 node (although it will permit multiple smaller `OP_RETURN`s up to the to
...
📝 ac12644 opened a pull request: "contrib: Fix gen-manpages.py to check build options"
(https://github.com/bitcoin/bitcoin/pull/33621)
# Fix gen-manpages.py to check build options
Fixes #17506
## Problem
The `gen-manpages.py` script generates UNIX manual pages based on the `--help` output from binaries. The options documented vary based on build system settings, but the manual pages checked into the repository should document as many options as possible.
## Solution
This PR adds comprehensive build option detection to ensure all available options are documented in the generated manpages.
## Changes Made
- **Added
...
(https://github.com/bitcoin/bitcoin/pull/33621)
# Fix gen-manpages.py to check build options
Fixes #17506
## Problem
The `gen-manpages.py` script generates UNIX manual pages based on the `--help` output from binaries. The options documented vary based on build system settings, but the manual pages checked into the repository should document as many options as possible.
## Solution
This PR adds comprehensive build option detection to ensure all available options are documented in the generated manpages.
## Changes Made
- **Added
...
💬 fanquake commented on pull request "Bump SCRIPT_VERIFY flags to 64 bit":
(https://github.com/bitcoin/bitcoin/pull/32998#issuecomment-3400943080)
Note that this caused the MSAN Fuzz job to start failing, so is being fixed / changed again in #33600.
(https://github.com/bitcoin/bitcoin/pull/32998#issuecomment-3400943080)
Note that this caused the MSAN Fuzz job to start failing, so is being fixed / changed again in #33600.
💬 optout21 commented on pull request "[IBD] coins: reduce lookups in dbcache layer propagation":
(https://github.com/bitcoin/bitcoin/pull/33602#discussion_r2428528999)
How about adding a default value `true` to the new `reallocate_cache` parameter, to suggest that that is the more common usage pattern? It also would reduce the diff a bit.
(https://github.com/bitcoin/bitcoin/pull/33602#discussion_r2428528999)
How about adding a default value `true` to the new `reallocate_cache` parameter, to suggest that that is the more common usage pattern? It also would reduce the diff a bit.
💬 maflcko commented on pull request "ci: Build ci_native_base image layer":
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400964861)
> * have a new (second) docker builder (with a fixed/shared `scope`) to build the base_image/imports it into the docker store
>
> * use a second build (with current ci config) which builds based on this base_image (which is now in the local docker store)
yeah, I think this makes sense. I just can't even figure out how to both support the gha cache backend and also the local storage.
We want to support:
* GHA "read-only" on branch pushes or pull requests, using the cache if available,
...
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400964861)
> * have a new (second) docker builder (with a fixed/shared `scope`) to build the base_image/imports it into the docker store
>
> * use a second build (with current ci config) which builds based on this base_image (which is now in the local docker store)
yeah, I think this makes sense. I just can't even figure out how to both support the gha cache backend and also the local storage.
We want to support:
* GHA "read-only" on branch pushes or pull requests, using the cache if available,
...