Bitcoin Core Github
43 subscribers
123K links
Download Telegram
πŸš€ fanquake merged a pull request: "refactor: Use immediate lambda to work around GCC bug 117966"
(https://github.com/bitcoin/bitcoin/pull/33113)
πŸš€ fanquake merged a pull request: "rpc: Fix 'getdescriptoractivity' RPCHelpMan, add test to verify fix"
(https://github.com/bitcoin/bitcoin/pull/33119)
πŸ’¬ fanquake commented on pull request "rpc: Fix 'getdescriptoractivity' RPCHelpMan, add test to verify fix":
(https://github.com/bitcoin/bitcoin/pull/33119#issuecomment-3159184025)
Backported to `29.x` in #33074.
πŸ€” fanquake reviewed a pull request: "cmake: Proactively avoid use of `SECP256K1_DISABLE_SHARED`"
(https://github.com/bitcoin/bitcoin/pull/33101#pullrequestreview-3091896535)
ACK b093a19ae2eff306b8ed6ce74d133e3ec53ef64e
πŸš€ fanquake merged a pull request: "cmake: Proactively avoid use of `SECP256K1_DISABLE_SHARED`"
(https://github.com/bitcoin/bitcoin/pull/33101)
πŸ’¬ ajtowns commented on pull request "p2p: never check tx rejections by txid":
(https://github.com/bitcoin/bitcoin/pull/33066#issuecomment-3159450863)
> I still think this PR is preferable to #33105. The latter will inevitably introduce more false-positive witness stripped errors,

I don't think false-positive witness stripped errors are harmful, apart from the CPU they required to be detected in the first place.

Only "misbehaving" peers will send us witness stripped txs in the first place, so the only benefit caching an error does (which is what we'd do if we replaced the "false" witness stripped result with something else) is only to pr
...
πŸ’¬ fanquake commented on pull request "cmake: Proactively avoid use of `SECP256K1_DISABLE_SHARED`":
(https://github.com/bitcoin/bitcoin/pull/33101#issuecomment-3159505982)
Guix Build (aarch64):
```bash
1a4f3c804b729fdc5a3d4831239b6bd7e34e0ca9061395578dfce07ffa8ea1cf guix-build-b093a19ae2ef/output/aarch64-linux-gnu/SHA256SUMS.part
03563287d5fd2f87829e2569e2fc02e8e6c0f9dc3db22d196fe442b852b242f0 guix-build-b093a19ae2ef/output/aarch64-linux-gnu/bitcoin-b093a19ae2ef-aarch64-linux-gnu-debug.tar.gz
5aee57e7e430fe8c7d0214dcc5717a1e50992fa9a28252804658fe262d6cde0e guix-build-b093a19ae2ef/output/aarch64-linux-gnu/bitcoin-b093a19ae2ef-aarch64-linux-gnu.tar.gz
d61969
...
πŸ’¬ pinheadmz commented on pull request "Add Docker support with multi-arch build and user permissions handling":
(https://github.com/bitcoin/bitcoin/pull/33139#issuecomment-3159533044)
concept NACK
willcl_ark's dockerhub repo is already outstanding: https://hub.docker.com/r/bitcoin/bitcoin even providing nightly builds!
πŸ“ fanquake opened a pull request: "[28.x] Backports "
(https://github.com/bitcoin/bitcoin/pull/33143)
Backports:
* #33133
πŸ’¬ fanquake commented on pull request "ci: Remove redundant RUN_UNIT_TESTS_SEQUENTIAL":
(https://github.com/bitcoin/bitcoin/pull/33136#discussion_r2256836237)
> to catch test case failures caused by dirty global state from prior test cases.

If the aim is to catch dirty state, should we run it in a job with the most unit tests? Windows cross-build is going to run less than Linux.
πŸ’¬ maflcko commented on pull request "ci: Remove redundant RUN_UNIT_TESTS_SEQUENTIAL":
(https://github.com/bitcoin/bitcoin/pull/33136#discussion_r2256852597)
I think it is always possible to miss unit tests that are not compiled. For the Windows ones, it should only be a few about windows paths, fork(), and socketpair, which seems fine to skip.

If there is need to run it in another task, it can be done as a follow-up?
πŸ’¬ cedwies commented on pull request "tests: cover abortrescan() in-flight True path with dynamic-tail retry":
(https://github.com/bitcoin/bitcoin/pull/33131#discussion_r2256883474)
I currently don't see a way around this. Any thoughts on how one could solve this problem?
πŸš€ fanquake merged a pull request: "kernel: create monolithic kernel static library"
(https://github.com/bitcoin/bitcoin/pull/33077)
πŸ’¬ fanquake commented on pull request "rpc: fix getpeerinfo ping duration unit docs":
(https://github.com/bitcoin/bitcoin/pull/33133#issuecomment-3159907692)
Backported to `28.x` in #33143.
πŸ’¬ fanquake commented on pull request "Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications":
(https://github.com/bitcoin/bitcoin/pull/33117#issuecomment-3160117477)
https://github.com/bitcoin/bitcoin/actions/runs/16728433539/job/47504424705?pr=33117#step:10:445:
```bash
D:\a\bitcoin\bitcoin\src\node\interfaces.cpp(115,40): error C2220: the following warning is treated as an error [D:\a\bitcoin\bitcoin\build\src\bitcoin_node.vcxproj]
D:\a\bitcoin\bitcoin\src\node\interfaces.cpp(115,40): warning C4101: 'e': unreferenced local variable [D:\a\bitcoin\bitcoin\build\src\bitcoin_node.vcxproj]
```
πŸ’¬ willcl-ark commented on pull request "ci: Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3160184649)
Force pushed to pick up changes in master (particularly #33002).

Other notable changes:
- Added a remote ccache host in 2adbe2caec. Previously we used actions/cache blobs for ccache. This works ~ ok, but Cirrus restores partial matches in reverse-age order (oldest first), which was resulting in bad cache hitrates for ccache when multiple caches existed for a job (say, "old" and "new"). The HTTP ccache backend is used on Cirrus infra and shared between all jobs. This requires using docker `-h
...
πŸ’¬ KaueTech commented on pull request "Add Docker support with multi-arch build and user permissions handling":
(https://github.com/bitcoin/bitcoin/pull/33139#discussion_r2257180805)
> I don't think it makes sense to enumerate them or even mention them. It should simply use the native arch. This can be achieved by just passing `--platform=linux`, like in the CI system

The TARGETARCH is only for the image build that downloads from bitcoincore.net, because it’s needed in the wget URL:
https://bitcoincore.org/bin/bitcoin-core-${VERSION}/bitcoin-${VERSION}-${ARCH}-linux-gnu.tar.gz

The image build from local code doesn’t need VERSION or ARCH.

The build from GitHub code
...
πŸ’¬ sipa commented on pull request "Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts":
(https://github.com/bitcoin/bitcoin/pull/32473#discussion_r2257185685)
Nice catch. Seems your fuzz test below (now included here) catches this.
πŸ’¬ sipa commented on pull request "Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts":
(https://github.com/bitcoin/bitcoin/pull/32473#discussion_r2257192024)
Maybe there are currently no tests that actually make use of this, but it's still correct: it's not illegal to have a signature with sighash type 0 in non-taproot, and it would need to be serialized as an actual 0 at the end.
πŸ’¬ sipa commented on pull request "Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts":
(https://github.com/bitcoin/bitcoin/pull/32473#discussion_r2257193373)
Good point. Gone.