blip-0038: block header gossip

[t-bast]

Lightning nodes must stay in sync with the blockchain to protect themselves against malicious peers that could publish revoked commitment transactions. Honest nodes should help their peers by letting them know about the latest block header they have received. This allows detecting when a node is behind and may need to fix their bitcoin node.

We extend lightning messages to include information about the last header we've received and the corresponding block height.

@Roasbeef can you detail what lnd is doing regarding this feature? You mentioned encoding it in ping and pong, but what exactly do you include?

[TheBlueMatt]

If we're just gonna include this once, should we include a proof that the given header is at the given height with a coinbase merkle path? I dunno maybe that means some nodes can't provide the proof, but giving a height value that can't be verified at all isn't that useful, in many cases :/

[t-bast]

If we're just gonna include this once

I think we'll want to include it in ping and pong as well, but I didn't do it yet, I'm waiting for @Roasbeef to let me know how they're currently encoding it in lnd first.

But it's probably a good idea to include whatever proof would help to validate the height, I'll need to look into this!

[guggero]

The current ping payload in lnd is the best block header serialized in the default wire format, so 80 bytes: https://github.com/lightningnetwork/lnd/blob/e61cba8d227faa959e1c591cafccf74a8ba98e30/peer/brontide.go#L582

[t-bast]

The current ping payload in lnd is the best block header serialized in the default wire format, so 80 bytes: https://github.com/lightningnetwork/lnd/blob/e61cba8d227faa959e1c591cafccf74a8ba98e30/peer/brontide.go#L582

This is directly encoded inside the ping message instead of using a TLV? That doesn't seem very future-proof, it doesn't support padding with random bytes to create ping messages of any chosen length? And it doesn't contain any magic byte to indicate that the ping contents contain a block header, so the reader just tries interpreting it as such and ignores it if that doesn't work?

Can you detail why that encoding was chosen? It feels like using an empty ping / pong content and using the TLV stream is more flexible, as it allows padding and combining with potentially other data we'd want to exchange in those messages.

[guggero]

I would guess that this is a case of "let's just prepare the code to be able to send a custom ping payload but then discuss the actual format at a later point", since we don't currently even look at the payload on the other side, it's just being logged (on trace level) and exposed on the RPC: lightningnetwork/lnd#5621

I do agree that using TLV here definitely makes sense.

[Roasbeef]

This is directly encoded inside the ping message instead of using a TLV? That doesn't seem very future-proof, it doesn't support padding with random bytes to create ping messages of any chosen length

Yeah it's just directly encoded, as there's no existing structure defined in the ping messages. Just as the requirement of pong is just to send the N random bytes.

And it doesn't contain any magic byte to indicate that the ping contents contain a block header, so the reader just tries interpreting it as such and ignores it if that doesn't work?

Up until now, there've been no readers 🤷 , they'd identify the payload based on the 80 byte length, and potentially knowledge of the prev block header referenced.

[Roasbeef]

An init message is only sent once when the connection is established. Putting the payload in ping would mean that the new headers can continually be sent and monitored.

To allow implementations to more easily distinguish the header message amidst a string of other random bytes in the payload, perhaps we can add special marker/magic bytes?

[t-bast]

I see two possible designs for this:

• keep the body of the ping messages random and include the block header in the message's tlv stream
• make the body of the ping message a TLV stream, that contains the block header (+ padding)