BOLT 1: add networks to init message.

[rustyrussell]

This has been discussed for forever, but now we have TLVs
the correct encoding seems obvious.

Signed-off-by: Rusty Russell rusty@rustcorp.com.au

[t-bast]

ACK, does this supercede #678 or does it only complement it?

[rustyrussell]

I think it replaces it, TBH. I'm not sure that query_channels means you should hang up.

[t-bast]

Sounds good then, I do think it supercedes it but wanted confirmation.

[Roasbeef]

We have no real support for cross-chain routing in the protocol as is today, as a result, what use is this?

[rustyrussell]

We have no real support for cross-chain routing in the protocol as is today, as a result, what use is this?

It means you can hang up if you accidentally connect to a testnet node?

[cfromknecht]

qq on how we define this (i'm not super familiar with the parsing code): intuitively i would think that this would be

  * [`tlvs`: `init_tlvs`]

where tlvs is the type, and init_tlvs is the name. the current way is flipped from what I would expect, maybe i'm just not thinking about it correctly?

[rustyrussell]

The type is actually defined below... Confusing I know, but it's a consequence of incrementally implementing parsing.

We could just imply TLV from now on, with msg foo having a foo_tlv implicitly?

[cfromknecht]

either works for me, was just curious what the guidelines are :)

[cfromknecht]

what is the prescribed action if some chains intersect but not all? would think receivers should restrict all messages they send to this intersection?

[rustyrussell]

Hmm, like @Roasbeef I haven't thought too hard about multi-chain implementation.

Hmm, I think that addition (SHOULD) would be positive, yes.

[Sword-Smith]

As a person who has accidently connected to several main net nodes with his test net node, I strongly support this pull request. With the added hope that the various implementations hang up if the network is wrong.

[rustyrussell]

OK, added the "don't forward gossip they're not interested in" sentence.

[rustyrussell]

FWIW, this was accidentally merged into the latest c-lightning master (ElementsProject/lightning#3300). Seems to have caused no issues on my test nodes, but explicit interop is probably desirable (i.e. someone else implement and check it works with ours):

Mainnet: 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605@128.199.202.16

Testnet:
031a3478d481b92e3c28810228252898c5f0d82fc4d07f5210c4f34d4aba56b769@165.227.30.200

And yeah, I tested that they refuse to maintain connections to each other now :)

[rustyrussell]

Trivial rebase, and whitespace cleanup.

[t-bast]

Seems to have caused no issues on my test nodes

I just tested that it doesn't cause any issue with existing eclair nodes; they simply ignore the TLV stream as expected.

I'll implement this and will let you know if compatibility is ok. Simply looking at the encoded TLV stream that c-lightning sends, it looks ok to me.

[cdecker]

Thanks @t-bast for checking. That puts my mind at ease

[t-bast]

I've implemented this on Eclair and tested compatibility with c-lightning, and there's a small issue.
Here are the test cases I ran:

• Eclair advertising NetworkA and c-lightning advertising NetworkA -> nodes stay connected -> OK
• Eclair advertising NetworkA and c-lightning advertising NetworkB -> nodes disconnect -> OK
• Eclair advertising [NetworkA, NetworkB] and c-lightning advertising NetworkB -> c-lightning disconnects -> NOK

This isn't an issue for Eclair/c-lightning compatibility since we support a single chain, but it may be an issue with lnd if they advertize Bitcoin+Litecoin: c-lightning would reject connections from such lnd nodes.

@rustyrussell @cdecker I think this is worth fixing quickly on c-lightning master branch.

[darosior]

@t-bast I think ElementsProject/lightning#3371 fixes that.

[t-bast]

This has been implemented by c-lightning and eclair.
I believe @cfromknecht ACK-ed in a previous IRC meeting, is that right?
In my opinion this just needs a rebase and can be merged.

[Roasbeef]

LGTM ⛷