💬 kanzure commented on issue "[SECURITY] Urgent Disclosure Coordination Request – High-Risk CI/CD Vulnerability":
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094559271)
If you now say you used the PGP keys, then why did you originally say you didn't find the PGP keys when you wrote your earlier messages? This is confusing and inconsistent.
None of your emails or messages have included your own pgp fingerprint or pgp key.
Using LLM to write your messages is not helping your case. It is not itself dispositive but the spam, multiple messages sent back to back with odd inconsistent edits, lack of detailed information such as PoC or patch, and inconsistent story i
...
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094559271)
If you now say you used the PGP keys, then why did you originally say you didn't find the PGP keys when you wrote your earlier messages? This is confusing and inconsistent.
None of your emails or messages have included your own pgp fingerprint or pgp key.
Using LLM to write your messages is not helping your case. It is not itself dispositive but the spam, multiple messages sent back to back with odd inconsistent edits, lack of detailed information such as PoC or patch, and inconsistent story i
...
💬 starixapp commented on issue "[SECURITY] Urgent Disclosure Coordination Request – High-Risk CI/CD Vulnerability":
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094561171)
Bryan,
You’re not reading — just reacting.
Let me walk you through what you’ve missed in your rush to sound authoritative:
1. I *did* find and use the official PGP keys to send the report.
2. I received *no response* — not even an automated acknowledgment — from `security@bitcoincore.org`.
3. There was no request for my PGP fingerprint or key because no human has replied to coordinate.
You keep pushing the narrative that this is about "believability."
This is not a personal trust issue. It
...
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094561171)
Bryan,
You’re not reading — just reacting.
Let me walk you through what you’ve missed in your rush to sound authoritative:
1. I *did* find and use the official PGP keys to send the report.
2. I received *no response* — not even an automated acknowledgment — from `security@bitcoincore.org`.
3. There was no request for my PGP fingerprint or key because no human has replied to coordinate.
You keep pushing the narrative that this is about "believability."
This is not a personal trust issue. It
...
💬 furszy commented on pull request "index: Deduplicate HashKey / HeightKey handling":
(https://github.com/bitcoin/bitcoin/pull/32997#discussion_r2217880735)
The base index class is responsible for detecting reorgs and calling the appropriate methods from the child class: `CustomRemove()` up to the forking point, then `CustomAppend()` to connect the new chain blocks. This happens during both initial sync and the validation event. I'm pretty confident we can safely remove the extra check.
Furthermore, since the index child class receives block connection and disconnection events in order, I don't see why it should care about reorgs at all (speaking
...
(https://github.com/bitcoin/bitcoin/pull/32997#discussion_r2217880735)
The base index class is responsible for detecting reorgs and calling the appropriate methods from the child class: `CustomRemove()` up to the forking point, then `CustomAppend()` to connect the new chain blocks. This happens during both initial sync and the validation event. I'm pretty confident we can safely remove the extra check.
Furthermore, since the index child class receives block connection and disconnection events in order, I don't see why it should care about reorgs at all (speaking
...
📝 bigshiny90 opened a pull request: "test: Add functional tests for blockreconstructionextratxn parameter"
(https://github.com/bitcoin/bitcoin/pull/33023)
This adds tests for the -blockreconstructionextratxn parameter which controls the extra transaction pool used for compact block reconstruction.
Uses RBF transaction pairs to populate the pool since that's a straightforward way to get transactions into the extra pool - send an original, then replace it with higher fee, and the original ends up in the extra pool.
(https://github.com/bitcoin/bitcoin/pull/33023)
This adds tests for the -blockreconstructionextratxn parameter which controls the extra transaction pool used for compact block reconstruction.
Uses RBF transaction pairs to populate the pool since that's a straightforward way to get transactions into the extra pool - send an original, then replace it with higher fee, and the original ends up in the extra pool.
👍 l0rinc approved a pull request: "p2p: rename GetAddresses -> GetAddressesUncached"
(https://github.com/bitcoin/bitcoin/pull/32994#pullrequestreview-3036097434)
Concept ACK, please consider splitting different change types to separate commits and adding extra qualifications to the methods that does the extra work.
(https://github.com/bitcoin/bitcoin/pull/32994#pullrequestreview-3036097434)
Concept ACK, please consider splitting different change types to separate commits and adding extra qualifications to the methods that does the extra work.
💬 l0rinc commented on pull request "p2p: rename GetAddresses -> GetAddressesUncached":
(https://github.com/bitcoin/bitcoin/pull/32994#discussion_r2217887924)
Even though the PR is quite simple, I'd separate the comment-changing-commits from the refactoring commits. I guess it may not make a lot of sense doing the rename with a scripted diff since it might confuse the two similarly named methods.
(https://github.com/bitcoin/bitcoin/pull/32994#discussion_r2217887924)
Even though the PR is quite simple, I'd separate the comment-changing-commits from the refactoring commits. I guess it may not make a lot of sense doing the rename with a scripted diff since it might confuse the two similarly named methods.
💬 l0rinc commented on pull request "p2p: rename GetAddresses -> GetAddressesUncached":
(https://github.com/bitcoin/bitcoin/pull/32994#discussion_r2217888892)
I'm wondering if it makes more sense to signal the lack of something here (which is only relevant because another similar method exists) instead of the additional functionality in the pair - i.e. leave this and rename the other to `GetAddressesCached`, since that's the one that has an additional functionality, not this one.
(https://github.com/bitcoin/bitcoin/pull/32994#discussion_r2217888892)
I'm wondering if it makes more sense to signal the lack of something here (which is only relevant because another similar method exists) instead of the additional functionality in the pair - i.e. leave this and rename the other to `GetAddressesCached`, since that's the one that has an additional functionality, not this one.
💬 fanquake commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#issuecomment-3094654338)
> I personally would prefer doing every single LogPrintf -> LogInfo inlining here in a scripted diff
#29641.
(https://github.com/bitcoin/bitcoin/pull/32967#issuecomment-3094654338)
> I personally would prefer doing every single LogPrintf -> LogInfo inlining here in a scripted diff
#29641.
👋 l0rinc's pull request is ready for review: "test: revive test verifying that `GetCoinsCacheSizeState` switches from OK→LARGE→CRITICAL"
(https://github.com/bitcoin/bitcoin/pull/33021)
(https://github.com/bitcoin/bitcoin/pull/33021)
💬 l0rinc commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#issuecomment-3094666136)
> #29641
Yes, I'm aware - was there a discussion that I missed for why we're not doing that instead?
(https://github.com/bitcoin/bitcoin/pull/32967#issuecomment-3094666136)
> #29641
Yes, I'm aware - was there a discussion that I missed for why we're not doing that instead?
✅ achow101 closed an issue: "[SECURITY] Urgent Disclosure Coordination Request – High-Risk CI/CD Vulnerability"
(https://github.com/bitcoin/bitcoin/issues/33022)
(https://github.com/bitcoin/bitcoin/issues/33022)
💬 starixapp commented on issue "[SECURITY] Urgent Disclosure Coordination Request – High-Risk CI/CD Vulnerability":
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094693429)
Let’s get something straight — both technically and ethically.
1. The issue reported was a **multi-stage CI/CD supply chain vulnerability**, not a syntax error or user complaint.
Dismissing it without technical review is a breach of every responsible disclosure principle in open source security.
2. The claim that “CI/CD cannot affect release builds” is not only inaccurate — it’s dangerously naive.
CI/CD affects everything *before* deterministic builds:
- Code review gates
-
...
(https://github.com/bitcoin/bitcoin/issues/33022#issuecomment-3094693429)
Let’s get something straight — both technically and ethically.
1. The issue reported was a **multi-stage CI/CD supply chain vulnerability**, not a syntax error or user complaint.
Dismissing it without technical review is a breach of every responsible disclosure principle in open source security.
2. The claim that “CI/CD cannot affect release builds” is not only inaccurate — it’s dangerously naive.
CI/CD affects everything *before* deterministic builds:
- Code review gates
-
...
⚠️ starixapp opened an issue: "Security Disclosure Mishandled by Bitcoin Core Maintainers"
(https://github.com/bitcoin/bitcoin/issues/33024)
Summary:
A serious coordinated disclosure of a CI/CD vulnerability chain impacting Bitcoin Core trust infrastructure was submitted responsibly, but met with the following:
- Dismissive behavior
- Public mockery of the researcher
- False technical claims downplaying CI/CD threat
- Closure of the GitHub issue without technical evaluation
#### Who was involved:
- **@achow101 (Ava Chow)** closed the issue without PoC review, discussion, or coordination.
- **@kanzure (Bryan Bishop)** mocked the dis
...
(https://github.com/bitcoin/bitcoin/issues/33024)
Summary:
A serious coordinated disclosure of a CI/CD vulnerability chain impacting Bitcoin Core trust infrastructure was submitted responsibly, but met with the following:
- Dismissive behavior
- Public mockery of the researcher
- False technical claims downplaying CI/CD threat
- Closure of the GitHub issue without technical evaluation
#### Who was involved:
- **@achow101 (Ava Chow)** closed the issue without PoC review, discussion, or coordination.
- **@kanzure (Bryan Bishop)** mocked the dis
...
✅ achow101 closed an issue: "Security Disclosure Mishandled by Bitcoin Core Maintainers"
(https://github.com/bitcoin/bitcoin/issues/33024)
(https://github.com/bitcoin/bitcoin/issues/33024)
💬 achow101 commented on issue "Security Disclosure Mishandled by Bitcoin Core Maintainers":
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094700656)
A reply to your security list email was already sent, which you have also replied to. We have not received any concrete details.
Do not open duplicate issues.
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094700656)
A reply to your security list email was already sent, which you have also replied to. We have not received any concrete details.
Do not open duplicate issues.
💬 starixapp commented on issue "Security Disclosure Mishandled by Bitcoin Core Maintainers":
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094702578)
You’re demanding technical details — in public — without offering any secure coordination, and acting like that’s the standard?
Who exactly are you in this security process?
Because unless you’re the official point of contact for responsible disclosures (with actual authority to manage vulnerabilities), I have zero reason to disclose anything sensitive through a GitHub issue, especially under your command.
Security 101: You don't pressure researchers to publish exploit chains in public.
You
...
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094702578)
You’re demanding technical details — in public — without offering any secure coordination, and acting like that’s the standard?
Who exactly are you in this security process?
Because unless you’re the official point of contact for responsible disclosures (with actual authority to manage vulnerabilities), I have zero reason to disclose anything sensitive through a GitHub issue, especially under your command.
Security 101: You don't pressure researchers to publish exploit chains in public.
You
...
💬 sipa commented on issue "Security Disclosure Mishandled by Bitcoin Core Maintainers":
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094707151)
No, we are absolutely not asking you to disclose anything through github.
You received a response to your email to the security list to follow the instructions on https://bitcoincore.org/en/contact/ for responsible disclosure. It has PGP keys.
(https://github.com/bitcoin/bitcoin/issues/33024#issuecomment-3094707151)
No, we are absolutely not asking you to disclose anything through github.
You received a response to your email to the security list to follow the instructions on https://bitcoincore.org/en/contact/ for responsible disclosure. It has PGP keys.
🤔 l0rinc reviewed a pull request: "coins: remove SetFresh method from CCoinsCacheEntry"
(https://github.com/bitcoin/bitcoin/pull/33018#pullrequestreview-3036128101)
Concept ACK
Very glad this is getting cleanup up, I found it worrying that a lot of tests were exercising invalid states in the first place - not the best foundation.
Quickly went over the changes, I find the small commits and excellent commit messages easy to follow.
I'll run a full IBD over this (maybe with some extra `SanityCheck` sprinkled around for extra measure) to make sure real usage doesn't trigger any invalid states we're not aware of.
(https://github.com/bitcoin/bitcoin/pull/33018#pullrequestreview-3036128101)
Concept ACK
Very glad this is getting cleanup up, I found it worrying that a lot of tests were exercising invalid states in the first place - not the best foundation.
Quickly went over the changes, I find the small commits and excellent commit messages easy to follow.
I'll run a full IBD over this (maybe with some extra `SanityCheck` sprinkled around for extra measure) to make sure real usage doesn't trigger any invalid states we're not aware of.
💬 l0rinc commented on pull request "coins: remove SetFresh method from CCoinsCacheEntry":
(https://github.com/bitcoin/bitcoin/pull/33018#discussion_r2217920312)
We should be able to remove `HaveCoin` now, since
```C++
bool CCoinsView::HaveCoin(const COutPoint &outpoint) const
{
return GetCoin(outpoint).has_value();
}
```
is more accurate (especially with the new extra assert)
(https://github.com/bitcoin/bitcoin/pull/33018#discussion_r2217920312)
We should be able to remove `HaveCoin` now, since
```C++
bool CCoinsView::HaveCoin(const COutPoint &outpoint) const
{
return GetCoin(outpoint).has_value();
}
```
is more accurate (especially with the new extra assert)
💬 l0rinc commented on pull request "coins: remove SetFresh method from CCoinsCacheEntry":
(https://github.com/bitcoin/bitcoin/pull/33018#discussion_r2217920517)
I understand if you think it may modify too many things here, but I'd prefer an actual `Assume` instead of the comment:
```suggestion
CoinsCachePair* Next() const noexcept
{
Assume(IsDirty());
return m_next;
}
```
(same for `Prev`)
(https://github.com/bitcoin/bitcoin/pull/33018#discussion_r2217920517)
I understand if you think it may modify too many things here, but I'd prefer an actual `Assume` instead of the comment:
```suggestion
CoinsCachePair* Next() const noexcept
{
Assume(IsDirty());
return m_next;
}
```
(same for `Prev`)