Skip to content

Implement BLS Signature Verification for InstantLocks #161

@QuantumExplorer

Description

@QuantumExplorer

Summary

BLS signature validation for ChainLocks and InstantLocks is currently incomplete in the dash-spv library. This is a critical security feature that must be implemented before the library can be used on mainnet.

Problem Description

Dash uses BLS (Boneh-Lynn-Shacham) threshold signatures to secure ChainLocks and InstantLocks through Long-Living Masternode Quorums (LLMQs). Currently, the SPV client accepts ChainLocks and InstantLocks without fully validating their BLS
signatures, which breaks Dash's security model and could allow acceptance of invalid locks.

Affected Code

ChainLock Validation

  • File: dash-spv/src/chain/chainlock_manager.rs:127
  • Status: Signature validation is stubbed out with TODO

InstantLock Validation

  • File: dash-spv/src/validation/instantlock.rs
  • Status: Signature validation incomplete

Without proper BLS signature verification:

  • The client could accept fraudulent ChainLocks that don't represent actual quorum consensus
  • The client could accept invalid InstantLock transactions that weren't actually locked by masternodes
  • This undermines the core security guarantees that Dash provides (long-range attack protection, double-spend prevention)
  • Users could be misled about transaction finality

What Needs to Be Done

  1. BLS Signature Verification Implementation

Implement full BLS signature verification that:

  • ✅ Retrieves the correct quorum public key for the quorum that signed the lock
  • ✅ Verifies the quorum existed at the required block height (8 blocks before ChainLock for chainlock validation)
  • ✅ Validates the BLS signature against the message hash and quorum public key
  1. Quorum Public Key Management

Ensure the client properly:

  • Tracks active quorums and their public keys
  • Maintains quorum history (quorums remain valid for a window of blocks)
  • Retrieves quorum info from masternode list diffs
  • Handles quorum rotation correctly
  1. Dependencies
  • Consider using/integrating a Rust BLS library compatible with Dash's BLS implementation (BLS12-381 curve)
  • Dash Core uses a modified version of the BLS library - ensure compatibility
  • May need FFI bindings to dashcore's BLS implementation or a compatible Rust crate
  1. Testing Requirements
  • Unit tests for BLS signature verification with known good/bad signatures
  • Integration tests using real mainnet ChainLocks and InstantLocks
  • Test cases for:
    • Valid signatures (should pass)
    • Invalid signatures (should fail)
    • Wrong quorum key (should fail)
    • Expired/non-existent quorums (should fail)
    • Malformed signatures (should fail gracefully)

Acceptance Criteria

  • BLS signature verification implemented for ChainLocks
  • BLS signature verification implemented for InstantLocks
  • Quorum public key retrieval working correctly
  • Invalid signatures are properly rejected, and nodes that relayed them get a short ban.
  • Comprehensive test coverage (unit + integration)
  • Documentation explaining the security model
  • All tests passing on testnet and mainnet data

Metadata

Metadata

Assignees

No one assigned

    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