Traditionally, vendors have preferred to delay disclosure to ensure patches are widely adopted, a stance that has been increasingly challenged by security researchers advocating for more immediate transparency. This shift is exemplified by Google's Project Zero, which follows a structured timeline for public disclosure: 90 days from the initial report to the software maintainers, or 30 days after a fix is released, provided it falls within 120 days from the first report. According to this schedule, a critical vulnerability identified on March 31 would expect public disclosure by June 29, following Project Zero's guidelines, or by July 26, considering the additional grace period after a patch release.

Despite the precedent set by entities like Google, Bitcoin Core adopts a more conservative approach to vulnerability disclosure. The project aims to balance the urgency of publicizing critical security flaws against the potential risks of premature disclosure. A recent issue described as a "consensus bug," capable of forcing a hard fork through a simple transaction, underscores the critical nature of such vulnerabilities and the complex considerations involved in deciding when to disclose them. While Bitcoin Core's policy might lean towards longer intervals before making such information public, the expectation set by other projects, such as btcd, suggests a commitment to a 90-day disclosure window, as indicated in their release notes and reinforced by their stated security policy, which only supports the latest major version.

This discrepancy in disclosure timelines highlights the ongoing evolution of security practices within the open-source community and the varying interpretations of what constitutes responsible disclosure. It emphasizes the need for clear, consistent policies that protect users while also fostering an environment of rapid response and transparency within the development community.