💬 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,
...
💬 optout21 commented on pull request "[IBD] coins: reduce lookups in dbcache layer propagation":
(https://github.com/bitcoin/bitcoin/pull/33602#discussion_r2428534723)
This `TODO` (and the one few lines below) seems to be independent of the change of this commit (it just exposes a pre-existing TODO condition), maybe isolate in a pre commit for clarity.
(https://github.com/bitcoin/bitcoin/pull/33602#discussion_r2428534723)
This `TODO` (and the one few lines below) seems to be independent of the change of this commit (it just exposes a pre-existing TODO condition), maybe isolate in a pre commit for clarity.
💬 optout21 commented on pull request "[IBD] coins: reduce lookups in dbcache layer propagation":
(https://github.com/bitcoin/bitcoin/pull/33602#issuecomment-3400973272)
Concept ACK 195fc2fe102197eae27c33b5e3969a6b15d1253a
Nice optimization
(https://github.com/bitcoin/bitcoin/pull/33602#issuecomment-3400973272)
Concept ACK 195fc2fe102197eae27c33b5e3969a6b15d1253a
Nice optimization
💬 maflcko commented on pull request "contrib: Fix gen-manpages.py to check build options":
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3400986174)
It may be good to retain the original author in the git commit. This can be achieved by cherry-picking or by adding the co-authored-by tag. Otherwise, it looks like you fully authored this yourself.
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3400986174)
It may be good to retain the original author in the git commit. This can be achieved by cherry-picking or by adding the co-authored-by tag. Otherwise, it looks like you fully authored this yourself.
💬 optout21 commented on pull request "coins: fix `cachedCoinsUsage` accounting in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#issuecomment-3400987547)
reACK 24d861da7894add47747eff69dd3fc71fbcdd7d0
(https://github.com/bitcoin/bitcoin/pull/32313#issuecomment-3400987547)
reACK 24d861da7894add47747eff69dd3fc71fbcdd7d0
💬 fanquake commented on pull request "contrib: Fix gen-manpages.py to check build options":
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3400995750)
> USE_UPNP - for UPnP arguments
This option doesn't exist in master?
> Users can rebuild with ./configure
No they can't?
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3400995750)
> USE_UPNP - for UPnP arguments
This option doesn't exist in master?
> Users can rebuild with ./configure
No they can't?
💬 willcl-ark commented on pull request "ci: Build ci_native_base image layer":
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400996834)
> We want to support:
>
> * GHA "read-only" on branch pushes or pull requests, using the cache if available, and building all layers locally (optionally falling back to the local storage for the base layer)
>
> * GHA "write-push" on main pushes, using the cache if available, and pushing to it (the base layer and the final image)
>
> * Cirrus (both of the above)
>
> * Fully local docker buildx (ideally, but optionally falling back to the local store for the base layer)
...
(https://github.com/bitcoin/bitcoin/pull/33620#issuecomment-3400996834)
> We want to support:
>
> * GHA "read-only" on branch pushes or pull requests, using the cache if available, and building all layers locally (optionally falling back to the local storage for the base layer)
>
> * GHA "write-push" on main pushes, using the cache if available, and pushing to it (the base layer and the final image)
>
> * Cirrus (both of the above)
>
> * Fully local docker buildx (ideally, but optionally falling back to the local store for the base layer)
...
✅ maflcko closed a pull request: "contrib: Fix gen-manpages.py to check build options"
(https://github.com/bitcoin/bitcoin/pull/33621)
(https://github.com/bitcoin/bitcoin/pull/33621)
💬 maflcko commented on pull request "contrib: Fix gen-manpages.py to check build options":
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3401001822)
Closing as a low-quality (and obviously wrong) LLM generated bot/spam patch, with an (obviously wrong) hallucinated explanation.
If you wish to contribute in the future, please focus on creating high-quality, original content that demonstrates a clear understanding of the project's requirements and goals. Also, see the [contributing guidelines](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#refactoring).
(https://github.com/bitcoin/bitcoin/pull/33621#issuecomment-3401001822)
Closing as a low-quality (and obviously wrong) LLM generated bot/spam patch, with an (obviously wrong) hallucinated explanation.
If you wish to contribute in the future, please focus on creating high-quality, original content that demonstrates a clear understanding of the project's requirements and goals. Also, see the [contributing guidelines](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#refactoring).