Skip to content

channeldb+migration: add type-prefixed waiting proof records#10633

Open
ellemouton wants to merge 2 commits intolightningnetwork:masterfrom
ellemouton:waitingproof-type-migration
Open

channeldb+migration: add type-prefixed waiting proof records#10633
ellemouton wants to merge 2 commits intolightningnetwork:masterfrom
ellemouton:waitingproof-type-migration

Conversation

@ellemouton
Copy link
Collaborator

Summary

Part of #10293 (Gossip 1.75 epic).

The waiting proof store holds half-proofs (AnnounceSignatures) while
we wait for the remote peer's matching half. To support gossip v2
(taproot channels), the store needs to handle both AnnounceSignatures1
and AnnounceSignatures2 payloads.

This PR adds a 1-byte type discriminator to every record so Decode
knows which wire message to parse, and introduces the codec machinery
for both proof types.

Record format

Before (legacy):

┌──────────┬───────────────────────────┐
│ isRemote │  AnnounceSignatures1      │
│ (1 byte) │  (wire payload)           │
└──────────┴───────────────────────────┘

After:

┌──────────┬──────────┬───────────────────────────┐
│   type   │ isRemote │  AnnounceSignatures*      │
│ (1 byte) │ (1 byte) │  (wire payload)           │
└──────────┴──────────┴───────────────────────────┘

Type byte values

Value Constant Payload Channels
0x00 WaitingProofTypeV1 AnnounceSignatures1 P2WSH
0x01 WaitingProofTypeV2 AnnounceSignatures2 + optional aggregate MuSig2 nonce Taproot

V2 payload detail

V2 records carry an optional aggregate nonce needed to reconstruct the
final MuSig2 signature:

┌───────────────┬──────────────────────┬─────────────────────┐
│ aggNonce flag  │ aggNonce (33 bytes)  │ AnnounceSignatures2 │
│ (1 byte bool)  │ (if flag set)        │ (TLV payload)       │
└───────────────┴──────────────────────┴─────────────────────┘

Commits

  1. channeldb: add type-prefix to waiting proof store records

    • Adds mandatory migration 35 that rewrites all existing records with
      a 0x00 type prefix
    • Updates WaitingProof.Encode/Decode to write/expect the prefix
    • Migration + codec change kept atomic so no intermediate revision can
      encounter unmigrated records
  2. channeldb: add V2 (taproot) waiting proof codec support

    • Introduces WaitingProofInner interface with V1WaitingProof and
      V2WaitingProof implementations
    • Encode/Decode now dispatch on the type byte
    • Gossiper updated with a V1 type assertion (full V2 gossiper
      integration will follow separately)
    • No live code path creates V2 proofs yet — this only lands codec
      • storage readiness

Test plan

  • Migration happy path: legacy records rewritten with type prefix
  • Migration key-mismatch: corruption detected and rejected
  • V1 encode prefix assertion
  • Unknown type decode rejection
  • V2 round-trip: with and without aggregate nonce
  • V2 store integration: add/get/remove through WaitingProofStore
  • make lint passes on both commits

Existing waiting proof records encode a bare isRemote flag followed by a
raw AnnounceSignatures1 payload. A future gossip v2 implementation will
store AnnounceSignatures2 (taproot) proofs in the same bucket, so each
record needs a discriminator byte to select the correct decoder.

This commit:

 1. Defines WaitingProofTypeV1 (= 0x00) for the current
    AnnounceSignatures1-based proofs.
 2. Adds migration 35, which rewrites every existing record to prepend
    the type byte.
 3. Updates WaitingProof.Encode/Decode to always write/expect the prefix.

The migration, codec changes, and tests are kept in one atomic commit so
there is no intermediate revision where the new Decode can encounter
unmigrated records.
@ellemouton ellemouton self-assigned this Mar 5, 2026
@gemini-code-assist
Copy link

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces foundational changes to the channeldb's WaitingProofStore to support the upcoming gossip v2 and taproot channels. It achieves this by implementing a new database migration that prefixes existing waiting proof records with a type byte, and by refactoring the WaitingProof structure to be type-agnostic through an interface. This allows the system to store and decode both legacy (V1) and new (V2, taproot-compatible) AnnounceSignatures payloads, preparing the database for future taproot channel announcements without immediately enabling their live creation or full gossiper integration.

Highlights

  • Database Migration 35: Introduced a mandatory database migration to prefix all existing WaitingProof records with a 0x00 type byte, signifying WaitingProofTypeV1.
  • Type-Prefixed Waiting Proofs: Modified the WaitingProof record format to include a 1-byte type discriminator, enabling the storage of different AnnounceSignatures versions.
  • Flexible Waiting Proof Structure: Refactored WaitingProof to embed a WaitingProofInner interface, allowing for distinct implementations like V1WaitingProof (for AnnounceSignatures1) and V2WaitingProof (for AnnounceSignatures2).
  • Taproot Channel Readiness: Added V2WaitingProof to support AnnounceSignatures2 payloads, including an optional aggregate MuSig2 nonce, laying the groundwork for taproot channel gossip.
  • Gossiper Adaptation: Updated the AuthenticatedGossiper to handle the new WaitingProof structure, explicitly asserting V1 proof types for current operations, with V2 integration planned for later.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog
  • channeldb/db.go
    • Imported migration35 package.
    • Registered MigrateWaitingProofStore as a mandatory database migration.
  • channeldb/log.go
    • Imported migration35 package.
    • Initialized logger for migration35.
  • channeldb/migration35/log.go
    • Added logging setup for the migration35 package.
  • channeldb/migration35/migration.go
    • Implemented database migration 35 to prefix existing waiting proof records with a V1 type byte.
  • channeldb/migration35/migration_test.go
    • Added unit tests for the MigrateWaitingProofStore database migration.
  • channeldb/waitingproof.go
    • Refactored WaitingProof to support multiple types (V1 and V2) using an interface.
    • Added V1WaitingProof and V2WaitingProof implementations.
    • Updated encoding/decoding logic to include a type prefix and dispatch based on it.
  • channeldb/waitingproof_test.go
    • Added tests for waiting proof encoding/decoding with type prefixes and V2 proof functionality.
  • discovery/gossiper.go
    • Updated handleAnnSig to explicitly cast waiting proofs to V1 type, preparing for V2 integration.
Activity
  • The author, ellemouton, has implemented a new database migration (35) to update the WaitingProofStore format.
  • The WaitingProof structure has been refactored to support multiple versions of AnnounceSignatures through an interface.
  • New V1WaitingProof and V2WaitingProof types have been introduced, with V2WaitingProof supporting an optional aggregate MuSig2 nonce for taproot channels.
  • The AuthenticatedGossiper has been updated to handle the new WaitingProof structure, with a temporary assertion for V1 proofs.
  • Comprehensive tests have been added for the migration, encoding/decoding of V1/V2 proofs, and store integration.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@ellemouton
Copy link
Collaborator Author

@codex review this

@ellemouton
Copy link
Collaborator Author

@claude review this

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a type prefix to WaitingProof records to support different gossip versions, specifically for upcoming Taproot channel support. It includes a database migration to update existing records to the new format. The WaitingProof struct is refactored to use an interface, making it extensible for future proof types. The changes are well-tested, including migration tests and unit tests for the new V2 proof logic. My review focuses on adherence to the repository's style guide regarding code documentation and formatting. I've suggested adding more in-body comments to explain the intention of code blocks, as recommended by the style guide.

@ellemouton ellemouton force-pushed the waitingproof-type-migration branch from 1588533 to d014f8f Compare March 5, 2026 11:24
@lightningnetwork lightningnetwork deleted a comment from claude bot Mar 5, 2026
@lightninglabs-deploy lightninglabs-deploy added the severity-critical Requires expert review - security/consensus critical label Mar 5, 2026
@ellemouton ellemouton force-pushed the waitingproof-type-migration branch from d014f8f to e583bdf Compare March 5, 2026 12:08
@lightninglabs-deploy lightninglabs-deploy added severity-critical Requires expert review - security/consensus critical and removed severity-critical Requires expert review - security/consensus critical labels Mar 5, 2026
@saubyk saubyk added this to v0.21 Mar 5, 2026
@saubyk saubyk moved this to In progress in v0.21 Mar 5, 2026
Introduce the WaitingProofInner interface and two concrete
implementations — V1WaitingProof (AnnounceSignatures1) and
V2WaitingProof (AnnounceSignatures2 + optional aggregate MuSig2 nonce).

WaitingProof.Encode/Decode now dispatch on the type prefix byte added
in the previous commit, so the store can transparently persist either
proof variant.

The gossiper is updated with a V1 type assertion to maintain existing
behaviour; full V2 gossiper integration will follow when taproot channel
announcements are wired up.

No live code path creates V2 waiting proofs yet — this commit only
lands the codec and storage readiness so the schema is in place before
new writers are introduced.
@ellemouton ellemouton force-pushed the waitingproof-type-migration branch from e583bdf to 93b713c Compare March 6, 2026 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gossip migration severity-critical Requires expert review - security/consensus critical

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

2 participants