Skip to content

taproot gossip #4663

@elnosh

Description

@elnosh

Issue for taproot gossip - lightning/bolts#1059
The upgrade specifies three distinct features:

  • option_gossip_v2 (70/71) node understands gossip v2 messages
  • option_gossip_v2_p2wsh (72/73) node can announce P2WSH channels through the v2 protocol
  • option_gossip_announce_private (74/75) node is able to announce a previously unannounced channel.

For an initial iteration, I think features option_gossip_v2 and option_gossip_v2_p2wsh could be covered
as option_gossip_announce_private is somewhat orthogonal to the new gossip protocol.

I started sketching out the changes that I think would be needed. Comments welcomed. If there is interest in adding it to LDK, I can work on it.

For option_gossip_v2 feature

  • Add v2 types ChannelAnnouncementV2, ChannelUpdateV2 and NodeAnnouncementV2
    • add CommonFields for channel_update/_2 and channel_announcement/_2 fields in common
  • Serialization of new message types added. Since v2 messages are pure TLV streams, we can add
    a new serialization macro similar to encode_tlv_stream but that can encode unknown TLVs. This is
    needed if we received an unknown odd TLV that was in the signed range. I looked at the BOLT-12
    code since the structs there are also TLV streams but IIUC, those keep a separate bytes field
    that is the serialized struct if there are any unknown fields that need to be preserved. Given
    that we need to persist these messages (for later forwarding), I think it's better to keep a
    separate excess_tlvs of unknown fields and serialize them ensuring they are kept in the correct
    ascending order to avoid storing those duplicate bytes.
  • Integrate new v2 message types into NetworkGraph Note: While the network upgrades, this will require storing both
    v1 and v2 messages.
  • Handlers for new messages - handle_channel_announcement_v2, channel update and node announcement v2 versions to P2PGossipSync
    • Apply block-height based rate limits for channel_update_2 and node_announcement_2
  • Handle inbound fees
  • Extend GossipTimestampFilter to include block height range TLV.
  • Add v2 messages to Message enum in the wire
  • Forward v2 messages

Channel verification

  • UtxoLookup changes. This trait is used to lookup UTXOs backing channels but is somewhat
    specific for v1 in that it only allows for querying by SCID. channel_announcement_2 message
    will also include an outpoint so a node with bitcoind backend with txindex enabled can query
    for it. This also requires verifying that both the outpoint and the SCID point to the same
    output. We can add a new method to UtxoLookup and the RPC/rest client impls.
  • MuSig2 key aggregation helper
  • MsgHash function for constructing the message to sign

For option_gossip_v2_p2wsh feature

  • Add announcement_node_pubnonce and announcement_bitcoin_pubnonce TLV fields to ChannelReady
    • If option_gossip_v2 and option_gossip_v2_p2wsh feature bits have been negotiated, exchange
      nonces in channel_ready. For new P2WSH channels this should be straightforward if both nodes support the feature.
      For old channels that have already been announced in current gossip protocol, it would require some handling
      to advertise the already existing channel with new protocol.
    • Similar nonce exchange extension for splice_locked after a splice has been confirmed.
  • Add AnnouncementSignaturesV2 message type. Needs calculating partial signatures
  • Aggregate partial signatures
  • Sign channel_announcement_2 messages
  • Extend UnsignedGossipMessage to include v2 messages channel_update_2 and node_announcement_2. Used by NodeSigner to sign_gossip_message
  • Handle update_channel_config calls from user if this generates more updates than the rate limit of one update per block

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions