From rusty at rustcorp.com.au  Sun Jul 14 01:38:06 2019
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sun, 14 Jul 2019 11:08:06 +0930
Subject: [Lightning-dev] [PROPOSAL] Gossip protocol v2
Message-ID: <87tvbpmm4h.fsf@rustcorp.com.au>

Hi all,

        At the last Summit we discussed using Schnorr sigs for gossip;
we'll also need to change things for taproot-based channels, so I think
it makes sense to combine the two changes.

channel_announcement drops from 430 to 140 (plus feature bitmap).
channel_update drops from to 136 to ~100 (assuming min & max specified)
node_announcement drops from 140 to >= 101 (plus alias, color, addresses).

Here's a rough draft based on what I think we've learned from current
gossip:

1. Optional fields are move into TLVs.
2. chain_id is moved into a TLV, with bitcoin mainnet being default.
3. Timestamp should be a block number.

This final rule gives natural ratelimiting: you can only add one update
per block.  SHOULD not use a block number from the last 60 seconds,
SHOULD use previous block number to allow for emergency updates, SHOULD
make bottom bit different from the previous update.

This plays much better with minisketch encoding, since even if we reduce
timestamp to 1 bit[1], propagation will Mostly Work.

Finally, it provides an implicit timestamp to channel_announcement,
which avoids the current dance we have to do (for the purposes of
timestamp filtering, the timestamp for channel_announcement is taken
from a channel_update).

Strawmen below:

1. type: 267 (`channel_announcementv2`)
2. data:
    * [`signature`:`musig_combo_signature`]
    * [`short_channel_id`:`short_channel_id`]
    * [`point`:`node_id_1`]
    * [`point`:`node_id_2`]
    * [`tlvs`:`channel_announcementv2_tlvs`]

- Where musig_combo_signature is the signature of the rest of the
  message using the node_ids and the bitcoin key.
- The bitcoin key can be read directly from the outpoint referred to
  by `short_channel_id`.
- One tlv record will be chain_id, the default being bitcoin mainnet.
- Another will be for feature bits.
- The timestamp is implicitly the block number + 6, see below.

1. type: 269 (`node_announcementv2`)
2. data:
    * [`signature`:`signature`]
    * [`u32`:`timestamp`]
    * [`point`:`node_id`]
    * [`tlvs`:`node_announcementv2_tlvs`]

- timestamp is simply a block number.
- tlvs contain optional alias, color.
- separate (odd) tlv types for each of IPv4/v6/Tor2/Tor3, length shows
  if it encodes multiple addresses.

1. type: 271 (`channel_updatev2`)
2. data:
    * [`signature`:`signature`]
    * [`short_channel_id`:`short_channel_id`]
    * [`u32`:`timestamp`]
    * [`byte`:`channel_flags`]
    * [`u16`:`cltv_expiry_delta`]
    * [`u32`:`fee_base_msat`]
    * [`u32`:`fee_proportional_millionths`]
    * [`tlvs`:`channel_updatev2_tlvs`]

- timestamp is a block number.
- channel_flags is direction and disable, as now.
- tlvs contains optional htlc_min_msat, htlc_max_msat, chain_hash (if
  not bitcoin mainnet).

Cheers,
Rusty.
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html