Using a blockheight 0 for unconfirmed transactions is a bit hacky.

To reduce the cardinality of channel types, only AnchorOutputsZeroFeeHtlcTx channels can support scidAlias or zeroConf.

I agree with that choice, it's a sensible one, but it means we won't be compatible with LDK (I believe they haven't shipped anchor outputs yet). But it's fine, we can wait for them to ship anchor outputs which should high be on their roadmap.

We do need to add tests to verify that we correctly reject channel types that use zero_conf or scid_alias with previous commitment types.

Note: a consequence of this is that the channel will only be zero-conf if the feature is set. It's not enough for the fundee to just trust us and send an early channel_ready because we will already have decided to wait for one conf (we would receive their alias in the channel_ready, but we put the watch before that in the channel fsm). I guess if we receive an early channel_ready with an alias, we can put a 2nd zero-conf watch, the first one will be ignored.

A bit reckless, even if option_zeroconf should only be enabled for a set of trusted peers.

Not really happy with the router listening to yet another event, but I couldn't find a better way to fix the race condition (see bf39b07).

At least I was able to have ChannelRelayer stop listening anymore to that same event 🤷

Note how for backward compatibility we set both the realShortChannelId_opt and localAlias to the same value. It may not actually be the real scid on feature branches.

⚠️ needs fixing, this is a dummy impl that leaks information on the creation date of the channel.

Since generating an alias only happens at channel creation, we can afford doing something "costly". For example this could be an AtomicLong that we initialize at startup by checking all currently assigned localAlias, and then we do an addAndGet with a random increment when we need to generate a new alias.

I don't think we really need a counter, wouldn't a randomLong() in the range that cannot be used by normal channels be enough?

We cannot afford a duplicate here though and the space isn't that big. We should expect a collision for 5 billion attempts on 64 bits and only 80k attempts for 32 bits right? https://en.wikipedia.org/wiki/Birthday_attack

It's true, the space isn't that big, but I'm afraid there may be privacy issues with generating those incrementally...I'll check what other implementations do

I did some maths to confirm this, let me know if my calculations look correct:

• scids are 64 bits long
• we want to reserve the range [0; 2^22] for real scids
• that leaves us with 2^42 available values for aliases
• we'll consider that we want to have 250k channels using aliases (~2^18)
• the probability of a collision is then p(n) ~= 2^36 / 2^43 ~= 0.8%

This is indeed not great! But using a counter that we increment leaks information about the approximate creation time of the channel, which could let an attacker find the channel outpoint on-chain...so I believe that what we should do instead is:

• generate an alias randomly in the [2^22:2^64] range
• check our alias map to see if it's already assigned and re-roll if it is

It means we'll probably need to send a message to the router to obtain a new alias, the router is where we can guarantee uniqueness.

I don't think we really need a counter, wouldn't a randomLong() in the range that cannot be used by normal channels be enough?

In a follow-up PR, we should introduce a whitelist of nodes from which we accept 0-conf channels. If nodes are in that whitelist, we should accept the channel_type even though they didn't set the feature in their init.

We should maybe even go further than that and use 0-conf with those peers even if the channel_type doesn't include it. Either they'll accept it and send their channel_ready, or they won't and it's ok, we'll just wait for their channel_ready automatically.