lnwire: add missing Gossip 1.75 fields and message #10232

ellemouton · 2025-09-22T10:28:54Z

This PR does the following main things:

adds the missing outpoint field to the ChannelAnnouncement2 message.
Defines the NodeAnnouncement2 message which will be used to represent the new node_announcement_1 message.

This is part of the gossip 1.75 project. None of these types are used in the projection code yet.

gemini-code-assist · 2025-09-22T10:29:28Z

Summary of Changes

Hello @ellemouton, I'm Gemini Code Assist¹! 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 lays foundational work for the Gossip 1.75 protocol by updating existing message definitions and introducing new ones. It primarily focuses on enhancing the ChannelAnnouncement2 with an outpoint field and creating a new NodeAnnouncement2 message, which leverages TLV for its fields. These changes ensure compatibility with future gossip protocol versions, although the new types are not yet actively used in the projection code.

Highlights

Gossip 1.75 Message Updates: The pull request introduces new message structures and fields to support the upcoming Gossip 1.75 specification. This includes adding a missing 'outpoint' field to the ChannelAnnouncement2 message and defining a new NodeAnnouncement2 message.
NodeAnnouncement Versioning: The existing NodeAnnouncement message has been renamed to NodeAnnouncement1 to differentiate it from the newly introduced NodeAnnouncement2. This change is reflected across various components that handle node announcements.
TLV Encoding for DNS Addresses and Outpoints: New TLV encoding/decoding logic has been added for DNSAddress and OutPoint types, allowing them to be seamlessly integrated into TLV-based messages like NodeAnnouncement2 and ChannelAnnouncement2.

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

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.

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. ↩

gemini-code-assist

Code Review

This PR updates the gossip protocol to version 1.75. The changes include renaming NodeAnnouncement to NodeAnnouncement1, adding an outpoint field to ChannelAnnouncement2, and defining the new NodeAnnouncement2 message. The implementation looks solid and includes relevant test updates.

I've found a few minor issues:

An incorrect static size for the OutPoint TLV record.
A typo in an error message in the Tor address encoder for NodeAnnouncement2.
Several new unexported functions are missing comments, which is required by the style guide. I've pointed out a few examples.

Overall, great work on moving the gossip implementation forward.

lnwire/outpoint.go

lnwire/dns_addr.go

lnwire/node_announcement_2.go

lnwire/outpoint.go

yyforyongyu

Pretty close - left a few comments about some improvements we can make.

yyforyongyu · 2025-09-25T10:01:19Z

lnwire/channel_announcement_2.go

 }

-// allNonSignatureRecordProducers returns all the TLV record producers for the
+// nonSignatureRecordProducers returns all the TLV record producers for the


yyforyongyu · 2025-09-25T10:13:19Z

lnwire/outpoint.go

+}
+
+// outpointEncoder is a TLV encoder for OutPoint.
+func outpointEncoder(w io.Writer, val interface{}, _ *[8]byte) error {


nit: can use val any, same below

yyforyongyu · 2025-09-25T10:19:57Z

lnwire/channel_update_2.go

+	// InboundFee is an optional TLV record that contains the fee
+	// information for incoming HTLCs.
+	// TODO(elle): assign normal tlv type?
+	InboundFee tlv.OptionalRecordT[tlv.TlvType55555, Fee]


I think we can just use FeeRecordType.

that just defines an int. we still need the tlv type here

(same was done in ChannelUpdate1)

yyforyongyu · 2025-09-25T10:22:34Z

lnwire/dns_addr.go

+
+		// Write the port as 2 bytes.
+		var portBytes [2]byte
+		err := WriteUint16(bytes.NewBuffer(portBytes[:0]), v.Port)


hmm why portBytes[:0] but not portBytes[:]

Totally agree that it's hard to read - so have updated with simplified version 👍

But out of interest:

portBytes[:0] creates a slice with zero length but the same underlying capacity as portBytes. This is used to reset the buffer position for bytes.NewBuffer() to start writing at the beginning of
the array.

If you used portBytes[:], it would create a slice with the full length (2 bytes) containing whatever data was previously in the array, which would interfere with the WriteUint16 function.

The [:0] slice gives bytes.NewBuffer an empty slice to start with, ensuring clean writes to the array.

yyforyongyu · 2025-09-25T10:22:55Z

lnwire/dns_addr.go

+}
+
+// dnsAddressEncoder is a TLV encoder for DNSAddress.
+func dnsAddressEncoder(w io.Writer, val interface{}, _ *[8]byte) error {


nit: can use any

yyforyongyu · 2025-09-25T10:25:16Z

lnwire/node_announcement_2.go

+		torV3 = tlv.ZeroRecordT[tlv.TlvType9, TorV3Addrs]()
+		dns   = tlv.ZeroRecordT[tlv.TlvType11, DNSAddress]()
+	)
+	stream, err := tlv.NewStream(ProduceRecordsSorted(


nit: newline above

yyforyongyu · 2025-09-25T10:29:16Z

lnwire/node_announcement_2.go

+func rgbEncoder(w io.Writer, val interface{}, _ *[8]byte) error {
+	if v, ok := val.(*Color); ok {
+		buf := bytes.NewBuffer(nil)
+		err := WriteColorRGBA(buf, color.RGBA(*v))


I think we can just pass w here? why creating the buf?

WriteColorRGBA takes a buffer pointer

yyforyongyu · 2025-09-25T10:35:42Z

lnwire/node_announcement_2.go

+				return err
+			}
+			onionService := tor.Base32Encoding.EncodeToString(ip[:])
+			onionService += tor.OnionSuffix


similar to how if len(host) != tor.V3DecodedLen above we should also validate len(onionService)

ellemouton

thanks @yyforyongyu 🙏

ellemouton · 2025-09-26T04:08:51Z

lnwire/channel_update_2.go

+	// InboundFee is an optional TLV record that contains the fee
+	// information for incoming HTLCs.
+	// TODO(elle): assign normal tlv type?
+	InboundFee tlv.OptionalRecordT[tlv.TlvType55555, Fee]


that just defines an int. we still need the tlv type here

ellemouton · 2025-09-26T04:09:08Z

lnwire/channel_update_2.go

+	// InboundFee is an optional TLV record that contains the fee
+	// information for incoming HTLCs.
+	// TODO(elle): assign normal tlv type?
+	InboundFee tlv.OptionalRecordT[tlv.TlvType55555, Fee]


(same was done in ChannelUpdate1)

ellemouton · 2025-09-26T04:18:12Z

lnwire/dns_addr.go

+
+		// Write the port as 2 bytes.
+		var portBytes [2]byte
+		err := WriteUint16(bytes.NewBuffer(portBytes[:0]), v.Port)


Totally agree that it's hard to read - so have updated with simplified version 👍

But out of interest:

portBytes[:0] creates a slice with zero length but the same underlying capacity as portBytes. This is used to reset the buffer position for bytes.NewBuffer() to start writing at the beginning of
the array.

If you used portBytes[:], it would create a slice with the full length (2 bytes) containing whatever data was previously in the array, which would interfere with the WriteUint16 function.

The [:0] slice gives bytes.NewBuffer an empty slice to start with, ensuring clean writes to the array.

ellemouton · 2025-09-26T04:23:11Z

lnwire/node_announcement_2.go

+func rgbEncoder(w io.Writer, val interface{}, _ *[8]byte) error {
+	if v, ok := val.(*Color); ok {
+		buf := bytes.NewBuffer(nil)
+		err := WriteColorRGBA(buf, color.RGBA(*v))


WriteColorRGBA takes a buffer pointer

Add a new OutPoint type that wraps wire.OutPoint and provides TLV encoding/decoding capabilities through the tlv.RecordProducer interface. This enables OutPoint to be used in TLV streams of messages.

The latest version of the spec has the outpoint included in the `channel_announcement2` message.

In preparation for adding a NodeAnnouncement2 struct along with a NodeAnnouncement interface, this commit renames the existing NodeAnnouncment struct to NodeAnnouncement1.

We leave a TODO that should be addressed after a discussion at the spec meeting. For now, having the incorrect TLV type is not a problem since this ChannelUpdate2 type is not used in production.

In preparation for using this type as a TLV record, we let it implement the RecordProducer interface.

In this commit, the lnwire.NodeAnnouncement2 type is defined. This will be used to represent the `node_announcement_2` message used in the Gossip 2 (1.75) protocol.

ellemouton self-assigned this Sep 22, 2025

ellemouton added the no-changelog label Sep 22, 2025

gemini-code-assist bot reviewed Sep 22, 2025

View reviewed changes

lnwire/outpoint.go Show resolved Hide resolved

lnwire/dns_addr.go Show resolved Hide resolved

lnwire/node_announcement_2.go Outdated Show resolved Hide resolved

lnwire/node_announcement_2.go Show resolved Hide resolved

lnwire/outpoint.go Outdated Show resolved Hide resolved

ellemouton added gossip protocol labels Sep 22, 2025

ellemouton force-pushed the g175MessageFollowup branch 2 times, most recently from 3d6fdbd to fc770dd Compare September 23, 2025 14:18

ellemouton requested review from bitromortac and yyforyongyu September 23, 2025 14:34

ellemouton force-pushed the g175MessageFollowup branch from fc770dd to 019dc79 Compare September 23, 2025 15:33

saubyk added this to v0.21 Sep 24, 2025

saubyk moved this to In review in v0.21 Sep 24, 2025

yyforyongyu reviewed Sep 25, 2025

View reviewed changes

yyforyongyu added this to the v0.21.0 milestone Sep 25, 2025

ellemouton force-pushed the g175MessageFollowup branch from 019dc79 to 3676d59 Compare September 26, 2025 04:28

ellemouton commented Sep 26, 2025

View reviewed changes

ellemouton force-pushed the g175MessageFollowup branch from 3676d59 to 72d41e1 Compare September 26, 2025 05:31

ellemouton added 7 commits September 29, 2025 09:30

lnwire: shorten method name

86f4ec0

lnwire: add OutPoint type with TLV encoding support

9801ce5

Add a new OutPoint type that wraps wire.OutPoint and provides TLV encoding/decoding capabilities through the tlv.RecordProducer interface. This enables OutPoint to be used in TLV streams of messages.

lnwire: add Outpoint to ChannelAnnouncement2

14f60a8

The latest version of the spec has the outpoint included in the `channel_announcement2` message.

multi: rename lnwire.NodeAnnouncement

77518c9

In preparation for adding a NodeAnnouncement2 struct along with a NodeAnnouncement interface, this commit renames the existing NodeAnnouncment struct to NodeAnnouncement1.

lnwire: add inbound fee to ChannelUpdate2

fd8406e

We leave a TODO that should be addressed after a discussion at the spec meeting. For now, having the incorrect TLV type is not a problem since this ChannelUpdate2 type is not used in production.

lnwire: let DNSAddress implement RecordProducer

3e48f68

In preparation for using this type as a TLV record, we let it implement the RecordProducer interface.

lnwire: define NodeAnnouncement2

1ccb590

In this commit, the lnwire.NodeAnnouncement2 type is defined. This will be used to represent the `node_announcement_2` message used in the Gossip 2 (1.75) protocol.

ellemouton force-pushed the g175MessageFollowup branch from 72d41e1 to 1ccb590 Compare September 29, 2025 07:31

ellemouton requested a review from yyforyongyu September 29, 2025 12:16

lnwire: add missing Gossip 1.75 fields and message #10232

Are you sure you want to change the base?

lnwire: add missing Gossip 1.75 fields and message #10232

Uh oh!

Conversation

ellemouton commented Sep 22, 2025

Uh oh!

gemini-code-assist bot commented Sep 22, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yyforyongyu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellemouton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!