Feature option_scid_alias separate from zero-conf

[pm47]

This is an alternative to #910, it is very close with the following changes:

• make zero-conf and scid alias independent
  Fundee may signal that it is willing to trust the funder by setting minimum_depth to zero, but that's unenforceable anyway.

• make scid alias and channel announcement independent
  There is no reason to advertize the "real" scid in funding_locked, because the real scid is already provided in announcement_signatures

• have nodes only advertise their ability to understand scid alias (feature option_scid_alias)
  If this feature is negotiated (both peers support it), then they must only use aliases (but that's unenforceable).

• accept that some combinations don't make sense, like "zero-conf without alias", or "alias and public channels"

[Crypt-iQ]

accept that some combinations don't make sense, like "zero-conf without alias", or "alias and public channels"

Some thoughts:

• Is it expected that zero-conf channels are always private even after being confirmed for some amount of time? I could see users wanting it public after some time. However, this amount of time would need to be signalled by using the minimum_depth field (e.g. non-zero) before sending AnnouncementSignatures?
• If A sends B a funding_locked early with an alias, and B responds early without an alias, the zero-conf channel can still be used but A will not be able to issue invoices. I think this "degenerate" case should be marked out explicitly.

[pm47]

Is it expected that zero-conf channels are always private even after being confirmed for some amount of time? I could see users wanting it public after some time. However, this amount of time would need to be signalled by using the minimum_depth field (e.g. non-zero) before sending AnnouncementSignatures?

I think the notion of "zero-conf" and "private/public" should be kept completely separate: private zero-conf channels stay private, public zero-conf channels stay public. Maybe it makes sense to support making channels go private->public but that is completely unrelated to zero-conf and this PR imo. The minimum_depth field relates to funding_locked, not announcement_signatures.

If A sends B a funding_locked early with an alias, and B responds early without an alias, the zero-conf channel can still be used but A will not be able to issue invoices. I think this "degenerate" case should be marked out explicitly.

That would be a spec violation though: if both peers support option_scid_alias, they must send an alias. Side note: funding_locked are never "early" because there is no way to be sure of the current block height.

[Crypt-iQ]

Ah I see announcement_signatures are only after 6 confirmations regardless of depth, so scratch my initial comment there. How can a zero-conf channel be public from the start if it does not have a short_channel_id assigned and only an alias? I was specifically referencing this "zero-conf without alias", or "alias and public channels" which seems to imply zero-conf cannot be public since it has an alias?

That would be a spec violation though: if both peers support option_scid_alias, they must send an alias.

What happens if an alias is not received?

[TheBlueMatt]

I'm a bit confused why this was opened as a new PR instead of discussing the requirements/changes you want here? I mean PRs are great, but but it seems if there's disagreement its a better use of everyone's time to hash it out in discussion first - there's alreay three PRs for this and a seeming lack of discussion around requirements.

make zero-conf and scid alias independent Fundee may signal that it is willing to trust the funder by setting minimum_depth to zero, but that's unenforceable anyway.

Why? You need an SCID alias in order for this to work, presumably?

have nodes only advertise their ability to understand scid alias (feature option_scid_alias)

Did you see my comment on 970? Should this be a channel type instead?

"alias and public channels"

One question on this - do we want to support this with an assumption that in the future we'll have public key aliases as well? Like, for non-routing payments that are just to the final node over a public channel, we may want to support that lost hop being "private" by having an alias, and if we support it here the only requirement is a public key alias which can come separately.

[pm47]

I'm a bit confused why this was opened as a new PR instead of discussing the requirements/changes you want here?

This is a follow up of #910 (review) detailing what I had in mind. Just easier to actually write it than explain with a lot of words -- and I think easier to understand the proposed changes too. But I get your point about further dividing the discussion, could have just linked a branch to the same effect. Doing that now and addressing your comments there.