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
Channel verification
For option_gossip_v2_p2wsh feature
Issue for taproot gossip - lightning/bolts#1059
The upgrade specifies three distinct features:
option_gossip_v2(70/71) node understands gossip v2 messagesoption_gossip_v2_p2wsh(72/73) node can announce P2WSH channels through the v2 protocoloption_gossip_announce_private(74/75) node is able to announce a previously unannounced channel.For an initial iteration, I think features
option_gossip_v2andoption_gossip_v2_p2wshcould be coveredas
option_gossip_announce_privateis 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_v2featureChannelAnnouncementV2,ChannelUpdateV2andNodeAnnouncementV2CommonFieldsforchannel_update/_2andchannel_announcement/_2fields in commonv2messages are pure TLV streams, we can adda new serialization macro similar to
encode_tlv_streambut that can encode unknown TLVs. This isneeded 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
bytesfieldthat 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_tlvsof unknown fields and serialize them ensuring they are kept in the correctascending order to avoid storing those duplicate bytes.
NetworkGraphNote: While the network upgrades, this will require storing bothv1 and v2 messages.
handle_channel_announcement_v2, channel update and node announcement v2 versions toP2PGossipSyncchannel_update_2andnode_announcement_2GossipTimestampFilterto include block height range TLV.Messageenum in the wireChannel verification
UtxoLookupchanges. This trait is used to lookup UTXOs backing channels but is somewhatspecific for v1 in that it only allows for querying by SCID.
channel_announcement_2messagewill 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
UtxoLookupand the RPC/rest client impls.MsgHashfunction for constructing the message to signFor
option_gossip_v2_p2wshfeatureannouncement_node_pubnonceandannouncement_bitcoin_pubnonceTLV fields toChannelReadyoption_gossip_v2andoption_gossip_v2_p2wshfeature bits have been negotiated, exchangenonces 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.
splice_lockedafter a splice has been confirmed.AnnouncementSignaturesV2message type. Needs calculating partial signatureschannel_announcement_2messagesUnsignedGossipMessageto include v2 messageschannel_update_2andnode_announcement_2. Used byNodeSignertosign_gossip_messageupdate_channel_configcalls from user if this generates more updates than the rate limit of one update per block