Allow More than one Address of a given type

[TheBlueMatt]

Its not uncommon to be multi-homed with different addresses, so we should probably allow nodes to do this. Also, it seems like this is pretty much universally not actually enforced on the network.

[t-bast]

At first glance it does make sense to allow multiple addresses of the same type.
But I'm wondering what the reasoning was to explicitly disallow it?

[TheBlueMatt]

I presume to ensure that space isn't wasted. But its not even about "allowing multiple" its about "bring the spec up to date with whats in the wild". AFAICT, lnd has been ignoring this part of the spec for a few years and, thus, no one actually seems to care about this requirement.

[t-bast]

We also allow multiple addresses of the same type in eclair, because why not?
ACK 86c2ebc

[cfromknecht]

LGTM, LND also allows more than one addr per type.

[fluxdeveloper]

If allowing multipe addresses of a given type, should it not be required that the addresses are ordered by their value in the message to ensure that the message can be reliably reconstructed for signature verification?

[t-bast]

should it not be required that the addresses are ordered by their value

If think the following requirement already covers that, doesn't it?

MUST place address descriptors in ascending order.

Actually you're totally right, this is needed if we want other users to reconstruct the list order. Otherwise you could brute-force the order until you get a match, since there shouldn't be too many addresses, but it's better if we provide an ordering that everyone follows.

[cfromknecht]

If allowing multipe addresses of a given type, should it not be required that the addresses are ordered by their value in the message to ensure that the message can be reliably reconstructed for signature verification?

I’m not sure imposing an order is required, they can just be stored in the order that we received them in. If we were to impose an ordering it’d have to be backwards compatible with existing implementations, which I suspect behave slightly different. Perhaps it does make sense tho to say that addresses of the same type should be ordered by preference?

[TheBlueMatt]

The current spec requires an order, so removing it or ordering by preference would be non-backwards-compatible. I don't see much reason to not leave it as-is. No harm in the connector deciding which they wish to connect over instead of connectee.

[cfromknecht]

The current spec requires an order, so removing it or ordering by preference would be non-backwards-compatible.

I was suggesting an intra-type ordering, which is backwards compatible with the spec because a single address is inherently sorted/ordered.

That being said, it’s definitely not critical and I’m totally fine leaving as is.

[TheBlueMatt]

Ah, right. I suppose if there is no order specified it probably makes sense to just call it "announcer's preference". But thats separate.

[rustyrussell]

It was actually introduced at @Roasbeef 's request, but apparently that was a misunderstanding. It's certainly valid to have multiple addresses, and as stated, most implementations allow it (c-lightning refuses to produce them, but will accept them).

Ack from me.

[TheBlueMatt]

Gonna merge given the ACKs. Further changes (@cfromknecht did you want more specificity here?) I'm happy to do as a follow-up PR.