Explicitly allow funding_locked early, and support alias scids (feat 46/47/50/51)

[rustyrussell]

This PR does three things:

1. Add support for channel aliases: a made up alias (can be independent for each side) unconnected to the real funding UTXO, by adding a TLV to funding_locked.
2. Allow a peer to insist that the alias always be used, never the real SCID, for privacy, using a new channel_type.
3. Allow a peer to indicate that it trusts the opener, and will allow zeroconf, using a new channel_type.

Closes: #895

[TheBlueMatt]

This seems to address all my questions/feedback I had while implementing, outside of the questions around feature bit in the previous PR - nodes that want to be able to use an alias for their incoming payments may still want to connect to nodes that implement sending aliases. That said, I dunno if anyone has any plans on implementing such peer-seeking behavior.

[TheBlueMatt]

So this implies we always send the thing we sent in our last revoke_and_ack (if there was a previous one)?. Just making sure we're all on the same page.

[Crypt-iQ]

I think this means send the per-commitment-point for the first commitment transaction (hence the #1)? Rather than the last one

[TheBlueMatt]

Yes, this changed in the second (fixup) commit that was pushed after this comment was made :).

[Crypt-iQ]

If option_scid_alias_only is negotiated and incoming HTLCs of the real short_channel_id are disallowed, does this break the spontaneous nature of key-send? The payer will need to know one of the alias short_channel_id which will be different from the publicly announced "real" one in the channel_announcement / channel_update messages. Additionally, regular routing may require a payer to know aliases of ALL option_scid_alias_only-negotiating hops along the way.

[TheBlueMatt]

scid aliases don't (currently) make sense for public channels - with the node ids public its obvious to the sender which channel is/isnt being used. They only really make sense to provide privacy to non-public nodes. Agreed this could be more clear here.

[Crypt-iQ]

It also makes sense in the zero-conf case before the scid is known

[TheBlueMatt]

Right, but that doesn't work for public channels - you have to announce all public channels with the "real" ID for anti-DoS reasons, this isn't unique to keysend. I think what you're really saying here is that option_scid_alias_only needs to disable announcements/imply/require the channel to be private.

[Crypt-iQ]

I was getting confused between the option and the TLV segment. Let's say the option isn't negotiated and a zero-conf channel is opened that is public after minimum_depth 6 confs. Keysend should work once public since routing to the real short_channel_id is allowed?

[TheBlueMatt]

Its already implied cause you're not allowed to set a public channel as scid_alias.

[Crypt-iQ]

The clause you're referencing only requires that if the option_scid_alias channel_type was negotiated rather than the feature bit?

[TheBlueMatt]

Yea, the current text of this PR, however, only adds the only-use-alias-when-forwarding requirement for the "channel_type has option_scid_alias set", which is correct, I believe. There is nothing implied by the feature bit here.

[Crypt-iQ]

For private zero-conf channels, this line seems to be ignored (the zero-conf and option-scid-alias channel types seem to be exclusive)

[TheBlueMatt]

I'm honestly entirely unsure what we're discussing here at this point - the above comments all seem to be on the same page - you can't set scid_alias on a public channel, and for private channels you can set it allowing the limiting of relay to the alias.

[TheBlueMatt]

@rustyrussell you'd mentioned previously this may make sense/need to be a channel type given the persistent scid alias info - I think I agree (but don't feel strongly at all really) - do you plan to update this PR?

[pm47]

I don't understand the point of option_scid_alias_only. Shouldn't a node just advertise its ability to understand scid aliases? Something like option_scid_alias.

Then if you want your peer to only use aliases, just request private channels? The only scid that will be used will be those provided in routing hints. Otherwise things gets confusing, as this comment thread shows: https://github.com/lightningnetwork/lightning-rfc/pull/910/files#r722406596.

[pm47]

"can simply start using the channel instantly" is misleading because you still need to wait for the counterparty's funding_locked before sending payments.

How about:

Suggested change

	Nodes which have funded the channel, or trust their peers to have
	done, or wish to use `push_msat` from other side's opening (without
	accepting incoming HTLCs) can simply start using the channel instantly
	by sending `funding_locked`.
	Nodes which have funded the channel, or trust their peers to have
	done, or wish to use `push_msat` from other side's opening (without
	accepting incoming HTLCs) can simply send their `funding_locked` right
	away. As soon as both parties have sent their `funding_locked`, the channel
	can be used even if the funding transaction hasn't yet been confirmed.

[pm47]

For public channels, the real short_channel_id is included in announcement_signatures. Why would we need to retransmit funding_locked?

[Crypt-iQ]

I think it could also suggest that announcement_signatures should only be sent after minimum_depth in case funding_locked is sent early realized announcement_signatures is only after 6 confirmations and is independent of minimum_depth

[Crypt-iQ]

Is this "may send multiple ..." during the lifetime of the channel?

[rustyrussell]

Yes, per channel...

[TheBlueMatt]

I don't understand the point of option_scid_alias_only.

No, this is critical to protect against probing.

[pm47]

Shouldn't a node just advertise its ability to understand scid aliases? Something like option_scid_alias.

I have explored this approach in this branch https://github.com/pm47/lightning-rfc/tree/zeroconf-as-alias-pm. In summary:

• 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"

I don't understand the point of option_scid_alias_only.

No, this is critical to protect against probing.

My point is if both parties support aliases, they must only use them. Why create a corner case where parties understand aliases but keep using real scids? Plus this is unenforceable anyway.

Answering #923 (comment):

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?

Not for e.g. Rusty's "spend push_msat" use case which is valid imo.

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?

Nope, I missed it (970??). I guess it could be a channel type (@t-bast wdyt?) but this is a separate concern from the semantics of this option.

"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.

That's a very good point: in fact, if we were to implement scid alias in Phoenix we would treat any channel alias as a node alias, because the general case is that a new channel may be created for a given payment (plus: only providing one routing hint reduces the size of the payment request). Also, putting Phoenix aside, given all (I think?) implementations do non-strict forwarding, there is no real difference between channel and node alias. This leads me to YA another alternative to this PR: have the alias be provided in the init tlv instead of funding_locked. Problem: we don't want to assign an alias to every incoming connection before there is a channel. Also, the alias could only rotate at reconnection, but that's fine for mobiles, which disconnect/reconnect all the time.

Answering #923 (comment):

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?

It's public in the sense that both peers have set the announce_channel bit in open/accept. This is a separate concern, unrelated to zero conf: we are in the same situation when a funding tx has more than minimum_depth and less than 6 confirmations.

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?

I guess it's a channel failure, or a warning, depending on how much you care.

[Crypt-iQ]

I agree that node alias is roughly the same as channel alias. I'm partial to the funding_locked alias though since it is simpler to implement for the lnd side. It meshes well with our current design of having channels be represented by ShortChannelID under-the-hood.

[rustyrussell]

I don't understand the point of option_scid_alias_only. Shouldn't a node just advertise its ability to understand scid aliases? Something like option_scid_alias.

Then if you want your peer to only use aliases, just request private channels? The only scid that will be used will be those provided in routing hints. Otherwise things gets confusing, as this comment thread shows: https://github.com/lightningnetwork/lightning-rfc/pull/910/files#r722406596.

Yes, text fixed.

The intent was that everyone should be setting this option in future, and thus respecting the alias. We can certainly rename it to option_scid_alias, which makes more sense?

[rustyrussell]

Shouldn't a node just advertise its ability to understand scid aliases? Something like option_scid_alias.

I have explored this approach in this branch https://github.com/pm47/lightning-rfc/tree/zeroconf-as-alias-pm. In summary:

* 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

True, and you won't be able to because it probably is still in mempool. Ah. You mean the requirement to re-xmit. OK, I'll remove that.

* 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).

Yep, done.

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

Zero-conf without alias would work for direct payments, but they're not generally useful. But aliases on public channels are good for routehints before funding tx is 6 deep.

I don't understand the point of option_scid_alias_only.

No, this is critical to protect against probing.

My point is if both parties support aliases, they must only use them. Why create a corner case where parties understand aliases but keep using real scids? Plus this is unenforceable anyway.

Yep. Spec now says this means you gotta ignore requests for "real" scid on unannouncable channels.

Answering #923 (comment):

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?

Not for e.g. Rusty's "spend push_msat" use case which is valid imo.

Or trust. But just supply a damn scid, it's easy :)

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?

Nope, I missed it (970??). I guess it could be a channel type (@t-bast wdyt?) but this is a separate concern from the semantics of this option.

"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.

That's a very good point: in fact, if we were to implement scid alias in Phoenix we would treat any channel alias as a node alias, because the general case is that a new channel may be created for a given payment (plus: only providing one routing hint reduces the size of the payment request). Also, putting Phoenix aside, given all (I think?) implementations do non-strict forwarding, there is no real difference between channel and node alias. This leads me to YA another alternative to this PR: have the alias be provided in the init tlv instead of funding_locked. Problem: we don't want to assign an alias to every incoming connection before there is a channel. Also, the alias could only rotate at reconnection, but that's fine for mobiles, which disconnect/reconnect all the time.

SCID inside an onion is a compact representation of the next node id. Always has been. It's only a direct channel reference for channel_update.

Answering #923 (comment):

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?

It's public in the sense that both peers have set the announce_channel bit in open/accept. This is a separate concern, unrelated to zero conf: we are in the same situation when a funding tx has more than minimum_depth and less than 6 confirmations.

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?

I guess it's a channel failure, or a warning, depending on how much you care.

I will close the channel. Don't do that :)

[rustyrussell]

Hmm, should we remove the requirement that announcement_signatures only be sent after funding_locked has been exchanged? We'll be always-sending "funding_locked" (which we should rename to channel_start or something), and I don't think anyone was waiting more than 6 blocks before anyway....

[pm47]

Looking good! Will implement and report back.

I don't think anyone was waiting more than 6 blocks before anyway....

We do: we scale confirmations for large channels, e.g. 30 blocks for 10+ BTC.

[pm47]

I think we are missing something in the channel_update section of BOLT 7:

• MAY create a channel_update to communicate the channel parameters to the channel peer, even though the channel has not yet been announced (i.e. the announce_channel bit was not set).
  - MUST NOT forward such a channel_update to other peers, for privacy reasons.
  - Note: such a channel_update, one not preceded by a channel_announcement, is invalid to any other peer and would be discarded.

This fake channel_update (required for the peer to build proper routing hints) should probably use the alias scid as shortChannelId? That's a bit dirty... We would send funding_locked and then channel_update.

Another option would be to not send the channel_update, instead let the peer pick arbitrary values for cltv_expiry and fees in its routing hints, and then rely on BOLT 4 failure messages. But that means an extra roundtrip between payer and sender, not great.

[rustyrussell]

Yerch... you need to use an alias, but whose, and which one?

I think the general rule here is "update_channel should use your own alias for unannounced channels". That works whether the update_channel is for an error response, as well as this case.

@TheBlueMatt wanted to allow multiple aliases, but this kills that idea, and I think it should be removed.

(Aside: I am looking at switching this to channel types, too: this makes far more sense when we try to upgrade, though it's a little more work in the short term. I'll try implementing it today...)

[TheBlueMatt]

Sorry I've been totally MIA on this PR, will get back to it in a week or two.

@TheBlueMatt wanted to allow multiple aliases, but this kills that idea, and I think it should be removed.

I think the general rule here is "update_channel should use your own alias for unannounced channels". That works whether the update_channel is for an error response, as well as this case.

Jumping on the tag, I don't see why? We can just make channel_update use the "real" scid, or 0, or whatever? Or we can use that to provide the aliases and not the funding_locked message? In any case, I'd strongly prefer to be able to rotate the "private" SCID - its quite useful for privacy, at least once we add pubkey aliasing. I'd prefer to not have to add SCID rotating when we get there and just do it while we're doing this anyway.

[rustyrussell]

You can't use 0, because we can have more than one channel. You can't use the "real" scid since it might not exist yet (zeroconf). You could send a channel_update every time the you get a new alias, I guess that's friendly (you call this channel 7x7x7? OK, here's the channel_update for "7x7x7").

I'm actually not sure what happens when we get a bad fee on a private channel, whether we send a channel_update or not. I'm pretty sure we don't in c-lightning. We should def. not leak the real scid in that case!

[rustyrussell]

Rotating can be probed without pubkey rotation which doesn't work without telling your peer what the association is (otherwise they can send via the new pubkey on the old channel scid, etc). And we decided not to do that, going for blinded paths instead.

This simply fixes the "look at my UTXO!!" problem.

[TheBlueMatt]

Rotating can be probed without pubkey rotation which doesn't work without telling your peer what the association is (otherwise they can send via the new pubkey on the old channel scid, etc).

Indeed, that's exactly what I said, gotta have pubkey aliases :)

And we decided not to do that, going for blinded paths instead.

"we" did? I think I'd love to go that route too, but last I heard work had largely stalled and there was some significant disagreement about trampoline and friends and how to build it appropriately. I'd love to learn that work is not stalled, however!

[rustyrussell]

Well, the onion message enctlv format is the same as the HTLC one, so hopefully progress in one leads to progress in the other?

[pm47]

I'm actually not sure what happens when we get a bad fee on a private channel, whether we send a channel_update or not. I'm pretty sure we don't in c-lightning. We should def. not leak the real scid in that case!

Side note: we considered using this mechanism to make the sender pay for on-the-fly channel creation in Phoenix (or split the cost between sender/receiver). Routing hints would have the "normal" feerate (the one if an existing channel could be used), but if a new channel needed to be created, our node would return a fee_insufficient failure with a new channel_update that has a steep fee increase to cover the channel creation cost. I think it's a really interesting use case, but we had two issues:

• implementations indeed do not correctly handle channel_updates for private channels
• that channel_update with high fees should be used just once, later payments should revert to the original low fees, which is not how channel_update works

[pm47]

I think the general rule here is "update_channel should use your own alias for unannounced channels". That works whether the update_channel is for an error response, as well as this case.

Agree, and maybe a good opportunity to introduce a new channel_flags message_flags bit to indicate that the provided short_channel_id is in fact an alias.

Bit Position	Name	Field
0	option_channel_htlc_max	htlc_maximum_msat
1	alias	This update uses an alias to identify the channel.

Would make it easier because since alias is not globally unique, the actual identifier for those channel_updates is actually node_id + alias.

[TheBlueMatt]

Well, the onion message enctlv format is the same as the HTLC one, so hopefully progress in one leads to progress in the other?

True! I guess what you're telling me is the issues that folks had are resolved, and I shouldn't worry and its definitely moving forward? If that's definitely the case than I'm totally happy to drop the alias-rotation stuff, I just figured it had ~no implementation cost and was an easy future win, given murkyness of trampoline's future.

[Crypt-iQ]

Another option would be to not send the channel_update, instead let the peer pick arbitrary values for cltv_expiry and fees in its routing hints, and then rely on BOLT 4 failure messages. But that means an extra roundtrip between payer and sender, not great.

lnd 0.13.1+ properly handles a channel update being returned in a failure message (lightningnetwork/lnd#5332). I think this may be fine but dirty, as long as the REAL scid isn't leaked for priv channels.

Would make it easier because since alias is not globally unique, the actual identifier for those channel_updates is actually node_id + alias.

I don't think it's possible to broadcast the channel_update for a private channel since nobody would be able to verify the alias. If we skip verification, then we introduce a DoS vector on the gossip layer. So perhaps the send-and-receive-update is the best we have for private channels. For public option_scid_alias channels, the channel_update can just use the REAL scid.

[TheBlueMatt]

Squashed down the fixup commits including two trivial changes from my end. Total diff since Rusty's last commit:

$ git diff-tree -U1 519be05f61e2c35ddf95b731203f89b4ee0946c3 34e9cd9
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index bb4780d..4fc760f 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -217,3 +217,3 @@ Each basic type has the following variations allowed:
   - `option_scid_alias` (bit 46)
-  - `option_zeroconf` (bit 48)
+  - `option_zeroconf` (bit 50)
 
@@ -512,3 +512,4 @@ The sender:
       - MUST set `alias` to a value not related to the real `short_channel_id`.
-    - MUST NOT send the same `alias` for multiple peers.
+    - MUST NOT send the same `alias` for multiple peers or use an alias which
+      collides with a `short_channel_id`  of a channel on the same node.
     - MUST always recognize the `alias` as a `short_channel_id` for incoming HTLCs to this channel.

[cdecker]

ACK 34e9cd9

[ghost]

3. Allow a peer to indicate that it trusts the opener, and will allow zeroconf, using a new channel_type.

Isn't this vulnerable to double spend?

[ellemouton]

@1440000bytes , yes it is. But this is why if you are on the receiver side you should only accept an htlc on such a channel if you trust the peer you are doing this with (in the pre-six-conf phase). You would not do this with someone that you think will double spend. So this will mostly be between a user and their LSP.