htlcswitch: add interceptor channel filter

[joostjager]

In #6232, a new command line flag --requireinterceptor was added. This is an essential flag for certain types of applications that use the htlc interceptor api. But at the same time, it is also a flag which may have too much power. If set and there's no interceptor registered, all forwards on the node will halt.

Applications that intercept traffic to a virtual channel really only need to be notified of htlcs that are bound for that channel. Regular forwards over real channels can proceed as normal.

This PR adds a channel filter flag htlc-interceptor-channel-filter to the htlc interceptor api so that the traffic that is intercepted can be limited. The goal is to decouple the availability of the node from the intercepting application as much as possible.

An alternative to this PR is to add a filter that makes the interceptor only intercept htlcs to unknown channels. This seems to be a more complex option, because the interceptable switch needs to be aware of all real channels. It also introduces edge cases where a channel doesn't exist yet, but when an htlc is replayed later, the channel does exist. This could mean that the htlc isn't offered to the interceptor anymore on the replay. Also with scid alias, a counterparty can open channels with scids in the full uint64 range. There is no reserved space as far as I know.

Todo:

• Add test coverage

[joostjager]

Looking for concept ack

[Crypt-iQ]

Also with scid alias, a counterparty can open channels with scids in the full uint64 range. There is no reserved space as far as I know.

the counterparty's scid alias isn't used for forwarding, the switch is only aware of our own scid aliases. lnd uses an scid starting with a block height of 16_000_000 -> max block height for a 24-bit number

[Crypt-iQ]

Could this instead be a list? Or are applications instead using a virtual scid for many channels such that this single uint64 is enough?

[joostjager]

I am not sure honestly. For my application, a single channel is sufficient. But I don't know about others. Maybe it could be a way to keep certain types of traffic apart. Making it a list is fairly cheap though, so I could do that.

[joostjager]

the counterparty's scid alias isn't used for forwarding, the switch is only aware of our own scid aliases. lnd uses an scid starting with a block height of 16_000_000 -> max block height for a 24-bit number

Ah ok. In code I also found this:

the starting ShortChannelID is 16000000:0:0 and the ending ShortChannelID is 16250000:16777215:65535.

With that we could define a range for virtual channels and make the filter a boolean flag indicating to only intercept htlcs destined for channels in the virtual channel range.

But not sure if that is better or worse than an explicit list of channels to intercept?

[Crypt-iQ]

With that we could define a range for virtual channels and make the filter a boolean flag indicating to only intercept htlcs destined for channels in the virtual channel range.

If these virtual channels are using scid's that are not allocated via the existing scid-alias mechanism, then the switch logic would need to be changed to account for this. This would be in handlePacketForward when it calls getLinkByMapping. Also the existing range is the scid-alias range for channels with peers that have negotiated the bit, so unless this channel is one of those, it should use a different range (maybe 16250001:0:0 and higher)

But not sure if that is better or worse than an explicit list of channels to intercept?

I think it's less complex to intercept an explicit list of channels, but here we cannot change the list of channels on the fly. I don't know if that prohibits certain use cases or not.

[joostjager]

If these virtual channels are using scid's that are not allocated via the existing scid-alias mechanism, then the switch logic would need to be changed to account for this.

Is this really necessary? I'd think that forwards over virtual channels will never even reach the switch. InterceptableSwitch will handle them, and if not, those forwards are supposed to fail?

I think it's less complex to intercept an explicit list of channels, but here we cannot change the list of channels on the fly. I don't know if that prohibits certain use cases or not.

Hard to say. For our use case, we just need to intercept a single scid. So either a single value or list works. Perhaps just go with that, because guessing at future requirements is usually not very successful?

[joostjager]

It seems that LDK is using a specific channel range as an interception condition: lightningdevkit/rust-lightning#1835

[lightninglabs-deploy]

@joostjager, remember to re-request review from reviewers when ready

[joostjager]

!lightninglabs-deploy mute