[Discussion] Direct Channels

[kilrau]

1. After some more real world experience with routing in lightning, I strongly believe we should have a "direct channel with every peer" approach for the foreseeable future (at least until AMP made it into lnd). I also put that in a recent tech paper update (CTRL+F "direct channel"). This will not only eliminate routing failures which probably will be in the 9X% range of for normal trade sizes, but also speed up swaps tremendously (ms vs s). Again, it's the plan to enable routing, once above two features are merged and have proven to increase routing success for larger amounts.

I would like to debate this general approach here.

2. To harden trading, this would need some stricter checks on direct channels: Since it's tough to know with which peer we'll be swapping beforehand, I propose to leave the current sanity checks upon placing an order as is. Additionally we should have a check on match if the inbound & outbound capacity of the direct channel with the peer is actually sufficient to execute the swap. If not... let ownOrder enter order book without matching peerOrder. It becomes a taker order then. Let's not forget events and log entries to inform the exchange/user that this happened. It could be like an additional check for the matching engine - check price, quantity & channel balance.

Opinions?

3. We should semi-automate channel opening with peers. This will be part of a "setup" process which I'm currently thinking about. sth along the lines, "Estimate your trading volume with X". xud will then open a channel with X.

Opinions?

[michael1011]

We should automate channel opening with peers

Lets say some malicious actors create a bunch of nodes and connect all of them your node. You would create channels to all of them and because you would like to start trading with the newly connected nodes as soon as possible the onchain transactions with which you want to create the channels have a high fee. Once the channels are open the malicious actor shuts down all of their infrastructure and you are stuck with a bunch of inactive channels. At some point you will force close them which takes some time and costs some more sats in onchain fees.

I think that automatically opening channels to random nodes that connect to you isn't a good idea. At least not if we don't have a way to prevent spam.

[sangaman]

I agree that automatic channel opening is susceptible to spam as described by michael.

If I were to automate anything, it might be opening reciprocal channels with peers who have connected to us. This is - at least until jointly funded channels are stable and supported - necessary to ensure payments can go both ways, and it makes spam attacks costly by requiring spammers to waste their own funds on transaction fees.

Additionally we should have a check on match if the inbound & outbound capacity of the direct channel with the peer is actually sufficient to execute the swap. If not... let ownOrder enter order book without matching peerOrder. It becomes a taker order then.

I don't think I follow here. Suppose we place an order and it matches with a peer order. We are already checking that a route exists to perform our side of the swap, if there is no route (or if the swap) fails we drop the peer order from the order book because it can't be executed. Are you proposing to change this behavior?

[kilrau]

Thanks for your feedback regarding automatically open channels! Indeed needs some more thinking and research on progress of dual-funded channels.

I don't think I follow here. Suppose we place an order and it matches with a peer order. We are already checking that a route exists to perform our side of the swap, if there is no route (or if the swap) fails we drop the peer order from the order book because it can't be executed. Are you proposing to change this behavior?

Yes. Because if we go for a direct channel approach (that's what I am suggesting in this issue), which strictly speaken means it's a requirement to have a direct channel in order to exchange orders with a peer, that check is not strict enough. Route exists - of course, we have a direct channel with the peer. I am talking about a local/remote balance check for the direct channel with the peer if it's enough to swap the order.

I know that sounds all very backwards, given the amazing routing capabilities of the lightning network. And again: this is only up to the point where routing larger payments becomes reliable.

But think about whom we have to convince that our software can be used in production in the not-too-distant future: few exchanges with very large orders and very high standards on swap success and speed.

[offerm]

But think about whom we have to convince that our software can be used in production in the not-too-distant future: few exchanges with very large orders and very high standards on swap success and speed.

These exchanges may open direct channels to have better visibility and control. But, I don't this that the network topology is a concern of XUD and certainly we should not force the exchanges to use direct channels.

Not to mention that channel has an amount which is locked in the channel and if you have N nodes you need N-1 channels, you would need to divide your amount by N-1 to set the channels. This is nice it you have high amount to allocate to N-1 channels and if you know N in advance. But it you start with 2 peer exchanges and after a few weeks you add 2 more, do you need to restructure all your channels?

Also, if N is high the avg channel size will be smaller than your intended trade size.

[kilrau]

I think that automatically opening channels to random nodes that connect to you isn't a good idea.

Agree.

I am talking about a local/remote balance check for the direct channel with the peer if it's enough to swap the order.

As described here, these two checks cover all, also for direct channels. No changes needed.

But, I don't this that the network topology is a concern of XUD

It is. Let me share my vision again: everything is managed through xud gRPC/CLI calls. No need for an exchange or a trader to ever touch the clients below. For that we need to know how the user wants to setup her channels. See docker issue.

certainly we should not force the exchanges to use direct channels.

Agree, we don't force anything - we just help to choose with good defaults and explainers. Includes help to create wallets & channels. Also see docker issue. So thanks to your feedback I propose both setups. Everybody d'accord? @michael1011 @sangaman @offerm @erkarl

Not to mention that channel has an amount which is locked in the channel and if you have N nodes you need N-1 channels, you would need to divide your amount by N-1 to set the channels. This is nice it you have high amount to allocate to N-1 channels and if you know N in advance. But it you start with 2 peer exchanges and after a few weeks you add 2 more, do you need to restructure all your channels? Also, if N is high the avg channel size will be smaller than your intended trade size.

Yes, all things to think about ... when we get there. I linked your comment in the docker issue so that we don't forget about it. Thx!

[kilrau]

Suma sumarum final proposal is to have two "modes":

• direct channels only (lnd auto-pilot off, we take care of opening direct channels with peers, white-list mode only)
• allow multi-hop-channels (use built-in auto-pilot to open channels)

The setup will help choose such based on usage (exchange vs individual trader etc). Is everybody onboard with this? I'd go ahead then and create an issue to define implemention details for the two modes. @erkarl @sangaman @offerm

[kilrau]

If no opposing opinions on this I take this as consensus? @sangaman @offerm

[sangaman]

I am still unsure about automatically opening channels, including the concerns over how much to open the channels for. Even in whitelist mode, we may have peers that we expect to trade a lot with and would want large channels with, and others that we don't expect to trade much with and would want small or no channels with, and I don't see how xud can know about these things in advance.

Also I don't see any reason not to allow multi-hop payments. It would only reduce our chance of being able to make successful swaps. Even in the case that we have channels with every peer, it's possible for the channel with a given peer to become temporarily unbalanced while it's still possible to pay that peer via different, multi hop route.

[kilrau]

Good points! @sangaman

I am still unsure about automatically opening channels, including the concerns over how much to open the channels for. Even in whitelist mode, we may have peers that we expect to trade a lot with and would want large channels with, and others that we don't expect to trade much with and would want small or no channels with, and I don't see how xud can know about these things in advance.

You are right, there is no way of knowing. We need user input. See Point 3. in what I wrote above. So let's call it "support" to setup channels, it's not automated. We need to ask "how much?" and "with whom?".

Also I don't see any reason not to allow multi-hop payments. It would only reduce our chance of being able to make successful swaps. Even in the case that we have channels with every peer, it's possible for the channel with a given peer to become temporarily unbalanced while it's still possible to pay that peer via different, multi hop route.

Right, but the probability that a random route is able to support a regular trade size is very low though. We can leave it open though. Would have to make the checks (point 2) less strict for that.

[ghost]

Considering the limitations of the current Raiden implementation I agree with temporarily hardening/restricting the trading to direct channels only.

[offerm]

I don't like it.

On Wed, Apr 24, 2019 at 4:23 PM Karl Ranna notifications@github.com wrote:

Considering the limitations of the current Raiden implementation I agree with temporarily hardening/restricting the trading to direct channels only.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ExchangeUnion/xud/issues/865#issuecomment-486227409, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKDI4WC7GRWJIOUMA67T3DPSBNNVANCNFSM4HC7OBXQ .

[ghost]

I don't like it.

I agree it's not ideal, but I'm suggesting it as a temporary measure in order to ensure smoother trading experience for the initial mainnet.

[kilrau]

Also agree it's not how we want it to be in the long term, but it's especially useful now and there will be parties with a "always" direct channels" need. Closing the discussion, and moving to implementation: https://github.com/ExchangeUnion/xud/issues/909