Taproot Pending Requirement Tracking

[arik-so]

• Protocol finalization
  • Nonce field labeling and breakdown
    For simplicity, I proposed the label partial_signature_with_nonce, which demarcates that particular nonce as not being precommitted, but rather being used for validation of the partial signature only.
  • Channel opening nonce location
    There has been back and forth as to whether local nonces should be precommitted to in the open_channel and accept_channel messages. I believe it makes little sense to commit to any nonce prior to the channel being accepted.
  • Channel closing specification (option_simple_close (features 60/61) lightning/bolts#1096)
  • Gossip protocol finalization
  • Make decisions on feature flags (currently: 30/31)
    • Settle on separate feature flag for Taproot gossip
  • Update graphics (originally created by me) for finalized version of the protocol spec?
• Cryptography
  • Create temporary Rust MuSig2 module (Preliminary MuSig2 implementation arik-so/rust-musig2#1)
  • Use temporary MuSig2 module behind cfg gate (Update messages for Taproot types. #2005)
  • Create bindings for libsecp-zkp
  • Swap out temporary Rust MuSig2 module for libsecp-zkp
  • Remove cfg gating for libsecp-zkp import
• Wire communication
  • Add cfg-gated Taproot-specific fields to channel operation messages (Update messages for Taproot types. #2005)
  • Add cfg-gated Taproot-specific fields to gossip messages
  • Add support for channel operation feature flag (Create Taproot feature and introduce signer type enum #2289)
  • Add support for Taproot gossip feature flag
• Channel operation
  • Create Taproot channel signer
    • Define Taproot signer interface
    • Define partial signature and nonce storage mechanism, where necessary
      It is necessary to store the latest precommitted local nonce and the latest committed local nonce, as well as the latest received remote nonce and received partial signature.
    • Implement InMemorySigner
    • Implement EnforcingSigner
  • Create enum to denote the type of signer used in a given channel (Taproot signer variant #2512)
  • Create switching mechanism to use correct signer based on channel type (Taproot signer variant #2512)
    • Introduce sensible separation between common and separate code paths depending on signer type
    • Verify that the switching mechanism doesn't break bindings
  • Channel opening
    • Handle inbound and outbound Taproot channel openings
    • Handle modified gossip to announce the new channel
    • Test interoperability of channel opening
    • Write unit and integration tests for channel opening
  • Channel updates
    • Add support for keeping track and updating of nonces as part of the regular channel operation
      • Modify the handling of HTLCs with Schnorr signatures
    • Modify gossip to send Schnorr signatures in channel updates
  • Channel closure
    • Determine coöperative close workflow and pending work (big question mark here)
    • Implement simple close (Implement new simple coop close #2433)
    • Handle unilateral closes
      • Detect breaches
      • Implement support for breach remedies
      • Implement support for Taproot-based anchor claims
      • Write unit tests to verify Taproot transactions are claimable in all scenarios
  • Modify fee calculation to reflect Taproot output types
    • Write unit tests to verify updated fee calculation
• Following thorough interop testing and spec finalization, remove cfg-gating
• Gossip parsing
  • Modify NetworkGraph to understand Taproot gossip
  • Learn to verify the onchain footprint of gossiped Taproot channels
  • Adjust RGS to include Taproot channels
    • Investigate feasibility of doing so in a backwards-compatible manner

[valentinewallace]

Mind posting about this on lightning/bolts#1078? Thanks!