⚠️ starixapp opened an issue: "[Vulnerability Coordination] Bitcoin Core Supply-Chain / CI-CD Integrity Issue – VU#237485"
(https://github.com/bitcoin/bitcoin/issues/33763)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

Hello,

I'm Alex Morgan from Sentinel Core. I have reported a supply-chain/CI-CD integrity issue that affects distributed Bitcoin Core binaries and requires technical coordination.

For context: KuCoin has indicated this falls within Bitcoin Core’s scope, and CERT/CC has opened a coordination case (VU#237485).

Please confirm receipt and provide a secure intake channel (PGP key/fingerprint
...

💬 starixapp commented on issue "[Vulnerability Coordination] Bitcoin Core Supply-Chain / CI-CD Integrity Issue – VU#237485":
(https://github.com/bitcoin/bitcoin/issues/33763#issuecomment-3477815293)
Requesting coordination: CERT/CC has opened case VU#237485 and KuCoin's security team has indicated this falls within Bitcoin Core's scope. Please confirm a secure intake channel (PGP fingerprint or secure upload endpoint) and a technical contact so we can provide a sanitized teaser for triage.

💬 Raimo33 commented on pull request "refactor: make script Solver's often-unused solutions parameter optional":
(https://github.com/bitcoin/bitcoin/pull/33757#issuecomment-3477847760)
> ```c++
> auto SolveType(CScript const& scriptPubKey) -> TxoutType;
> ```

I agree on having a separate method for this. It was my initial approach. It involves some code duplication and adding an extra test but might be worth it to avoid all the `if (vSolutionsRet)` checks.

> ```c++
> auto Solve(CScript const& scriptPubKey) -> std::tuple<TxoutType, std::vector<std::vector<unsigned char>>>;
> ```

Wouldn't this increase allocs/copies? I'd say it's perfectly fine to leave it as is w
...

✅ fanquake closed an issue: "[Vulnerability Coordination] Bitcoin Core Supply-Chain / CI-CD Integrity Issue – VU#237485"
(https://github.com/bitcoin/bitcoin/issues/33763)

💬 fanquake commented on issue "[Vulnerability Coordination] Bitcoin Core Supply-Chain / CI-CD Integrity Issue – VU#237485":
(https://github.com/bitcoin/bitcoin/issues/33763#issuecomment-3477848117)
> and provide a secure intake channel (PGP key/fingerprint

See https://bitcoincore.org/en/contact/. You can send an email to `security@bitcoincore.org` using one of the keys listed there.

💬 fanquake commented on pull request "cli: rework -addrinfo cli to use addresses which aren’t filtered for quality/recency":
(https://github.com/bitcoin/bitcoin/pull/26988#issuecomment-3477855579)
> not yet tested with a server running pre-v26 (before getaddrmaninfo)

`25.x`, `26.x` and `27.x` are end-of-life? So that seems out of scope for needing to test / accomodate code-wise?

🤔 TheCharlatan reviewed a pull request: "kernel: Introduce C header API"
(https://github.com/bitcoin/bitcoin/pull/30595#pullrequestreview-3408737974)
Thanks for the review @stringintech!

Updated e9f14a07ed8b8161840d739c24603539119ee5fd -> e95efc00842d5d0df96ee9294cdf818741be539e ([kernelApi_79](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_79) -> [kernelApi_80](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_80), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_79..kernelApi_80))

* Addressed @stringintech's [comment](https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2483514108), simplified chec
...

💬 TheCharlatan commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2484755640)
I made `GetBlockTreeEntry` an optional now. The developer might not have a way to check inclusion of a certain block hash, so returning an optional seems better. For `GetByHeight`, I would keep the throw, because it is a bit easier to directly plug into the range, and because we have a way for the programmer to guard against bad height values by checking it against the `Height()`.

💬 sipa commented on pull request "cli: rework -addrinfo cli to use addresses which aren’t filtered for quality/recency":
(https://github.com/bitcoin/bitcoin/pull/26988#issuecomment-3477872095)
Concept ACK, but I think it's weird to use a long English phrase as field name. Maybe just "addresses_total" and "addresses_filtered" or so? If we care about backward compatibility, we could add a `-deprecatedrpc=addresses_known` option to enable the "addresses_known" field (which would be a copy of "addresses_filtered").

💬 sipa commented on pull request "refactor: make script Solver's often-unused solutions parameter optional":
(https://github.com/bitcoin/bitcoin/pull/33757#issuecomment-3477874632)
If we're going to touch this code, my preference would be to go with @purpleKarrot's approach of two separate functions, moving the `vSolutions` field into a return pair element.

If the allocation overhead of that is a concern, I think the proper solution is a follow-up to get rid of the `vSolutions` approach of encoding things, and instead introduce a proper type that encodes it more usefully (possibly an `std::variant`, like `CTxDestination`, but with more possibilities). For multisig-like
...

🤔 sipa reviewed a pull request: "refactor: inline constant return values from `dbwrapper` write methods"
(https://github.com/bitcoin/bitcoin/pull/33042#pullrequestreview-3408745524)
ACK 743abbcbde9e5a2db489bca461c98df461eff7d0

💬 stringintech commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3477890834)
ACK e95efc00

💬 achow101 commented on issue "Download links on bitcoincore.org not working":
(https://github.com/bitcoin/bitcoin/issues/33762#issuecomment-3477997646)
> clicking the download buttons returns an error

What is the error?

✅ l0rinc closed a pull request: "refactor: make script Solver's often-unused solutions parameter optional"
(https://github.com/bitcoin/bitcoin/pull/33757)

💬 l0rinc commented on pull request "refactor: make script Solver's often-unused solutions parameter optional":
(https://github.com/bitcoin/bitcoin/pull/33757#issuecomment-3478002392)
Thank you for the comments, appreciate the high-level comments!

@purpleKarrot, I though of both solutions you have suggested (I also passionately hate output parameters) but since I meant this as a call-site-simplification while eliminating useless work (though the cases where the `vSolutions` was still needed *was* indeed slightly more awkward), populating the vector just to discard it immediately didn't seem like it would solve anything.

> and instead introduce a proper type that encodes
...

💬 l0rinc commented on pull request "refactor: optimize: avoid allocations in script & policy verification":
(https://github.com/bitcoin/bitcoin/pull/33645#discussion_r2484842410)
I have removed my nack here, see https://github.com/bitcoin/bitcoin/pull/33757#issuecomment-3478002392

I'm not sure about the focus for the other commits, they seem like problems that you *can* solve instead of problems that *need* solving.
The resulting code isn't obviously cleaner and the dependencies are often more complicated now (reusing vectors for example). I know that was already in place, but most of our work is untangling code, I'm more enthusiastic about changes that are both clea
...

💬 bronsii commented on issue "Download links on bitcoincore.org not working":
(https://github.com/bitcoin/bitcoin/issues/33762#issuecomment-3478023268)
It works now.

Ava Chow ***@***.***> schrieb am So. 2. Nov. 2025 um 15:15:

> *achow101* left a comment (bitcoin/bitcoin#33762)
> <https://github.com/bitcoin/bitcoin/issues/33762#issuecomment-3477997646>
>
> clicking the download buttons returns an error
>
> What is the error?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/33762#issuecomment-3477997646>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BZS5
...

💬 TheBlueMatt commented on pull request "Embed default ASMap as binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#issuecomment-3478028040)
I couldn't really find a better place to leave this comment, even though its clearly not really quite targeted at this PR itself (which is awesome!), so I'll leave it here and y'all can yell at me for not finding the right place later.

I saw in the core-dev writeups that there appears to be some intent to build asmap files based on only RPKI data (if that's wrong, please skip the rest of this comment). I fear that that is a particularly bad idea.

While RPKI deployment has been quite succes
...

📝 hebasto opened a pull request: "ci: Add Windows + UCRT jobs for cross-compiling and native testing"
(https://github.com/bitcoin/bitcoin/pull/33764)
This PR is part of the ongoing effort to migrate to the modern UCRT runtime for cross-compiled Windows binaries, including release builds.

For more details about this migration, see:
- https://github.com/bitcoin/bitcoin/issues/30210
- https://github.com/bitcoin/bitcoin/pull/33593

A few items are outside the scope of this PR and are left for follow-up work:
1. The version of Debian's [cross-compiler](https://packages.debian.org/trixie/g++-mingw-w64-ucrt64) is 14.2.0, which differs from v
...

💬 sipa commented on pull request "Embed default ASMap as binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#issuecomment-3478053233)
@TheBlueMatt FYI, the repository with asmap construction scripts is https://github.com/asmap/kartograf. My understanding (which may be incomplete) is that RPKI is used where available, but supplemented with other sources.