Skip to content

chore: Hex normalization bug in ResumeFinalityProposal #1979

Description

@RafilxTenfen

Cantina AI BABY-2

Summary

HandleResumeFinalityProposal compares raw, user‑supplied BTC public key hex strings against canonical lowercase encodings generated by MarshalHex(). Because the underlying parser accepts mixed‑case hex, proposals may supply valid keys whose casing prevents them from matching canonical voter records or canonical cache entries. This breaks two intended safeguards: the handler can incorrectly conclude that a finality provider did not vote at the halting height, and the subsequent voting‑power cache rewrite may fail to zero or jail the intended provider. As a result, a provider may become jailed in btcstaking while still being counted as active in finality power calculations, causing quorum to become unreachable and blocking the protocol’s recovery path. The bug can be triggered accidentally by non‑canonical tooling or user input.

Details
  • Explanation:
    GetVoters stores keys using canonical lowercase encodings, but HandleResumeFinalityProposal records and checks keys using the raw proposal strings. Mixed‑case keys therefore bypass voter checks and fail to match during cache reconstruction, leaving jailed providers’ voting power intact.

  • Root cause:
    Inconsistent hex canonicalization between proposal processing and internal state management; canonicalization occurs after parsing, but proposal inputs are never normalized.

  • Code location:

Mitigation: Normalize hex to lowercase immediately after parsing.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions