docs: update security vulnerability reporting guidance

[mdan5678-dotcom]

Summary

This updates SECURITY.md to remove stale Bitcoin Core vulnerability reporting details and replace them with Bitgesell-appropriate security reporting guidance.

Why

The existing security policy points reporters to security@bitcoincore.org and lists Bitcoin Core developer PGP keys, which are not appropriate reporting contacts for this repository.

Changes

• Ask reporters not to disclose vulnerabilities in public GitHub issues.
• Recommend GitHub private vulnerability reporting when available.
• Direct reporters to official Bitgesell project channels when private reporting is unavailable.
• Add a short checklist of useful vulnerability report details.

Testing

Documentation-only change.

[MyTH-zyxeon]

Review-assist / deconfliction note for maintainers on #352:

I checked this against the existing security-policy PR queue. Current visible state: OPEN / MERGEABLE / mergeStateStatus=CLEAN at head e670d652732558b4547a7fbbdb111e1c3bc49c57, no visible comments/reviews/checks, and a one-file SECURITY.md docs-only diff (+16/-10).

This overlaps heavily with #226, which already removes the inherited Bitcoin Core security email and developer PGP keys, points reporters away from public issues, and gives private vulnerability reporting / official website fallback guidance.

Main maintainer decision before merging either one:

• If security: remove Bitcoin Core reporting contacts #226 is preferred because it uses the explicit security/advisories/new flow and https://bitgesell.ca fallback, close/supersede docs: update security vulnerability reporting guidance #352 or ask the author to rebase it as a checklist-only follow-up.
• If docs: update security vulnerability reporting guidance #352 is preferred, please confirm private vulnerability reporting is enabled or add one concrete private contact path; otherwise reporters may still lack a direct non-public channel.
• For bounty classification, I would treat docs: update security vulnerability reporting guidance #352 and security: remove Bitcoin Core reporting contacts #226 as the same security-policy cleanup lane, not as two unrelated payout candidates.

No code, wallet/RPC, consensus, live-chain, claim, or payment action from me here; this is queue triage to avoid duplicate review effort.

[mdan5678-dotcom]

Thanks for the review-assist note. That makes sense.

My intent with #352 was to remove stale inherited Bitcoin Core security reporting guidance and make the Bitgesell vulnerability reporting instructions clearer.

I understand there may be overlap with #226. I do not want to create duplicate review work.

If maintainers prefer #226 as the primary security-policy cleanup path, I am happy to rework #352 into a narrower checklist-only follow-up, or otherwise adjust based on maintainer direction.

I will wait for maintainer guidance before making further changes.

[MyTH-zyxeon]

Thanks for clarifying. From a maintainer-triage standpoint, that leaves a clean path:

• keep security: remove Bitcoin Core reporting contacts #226 as the primary security-policy cleanup if the project wants the explicit GitHub private-advisory flow plus official-site fallback;
• use docs: update security vulnerability reporting guidance #352 only as a narrower checklist/report-quality follow-up after that direction is confirmed; or
• if maintainers prefer docs: update security vulnerability reporting guidance #352 instead, add one concrete private contact/advisory path so reporters are not left with only public-channel guidance.

I would still keep #226/#352 on the same security-policy bounty lane until a maintainer chooses which one should be canonical, so there is no duplicate payout/review queue.