[Lightning-dev] Generalizing proportional routing fees to exchange rates

[Christian Decker]

On Tue, May 23, 2017 at 06:41:33PM -0400, ZmnSCPxj via Lightning-dev wrote:
> >There needs to be more information across networks than just the
> >exchange rate. For example, you need to know the block numbers for CLTV
> >timeouts on both sides, and you need to know the topology of the
> >network on both sides. Those are problems we can push to the edges
> >of the network, and nobody else should notice.
> 
> Do you mean, there will be some special LN variant or service
> specifically for cross-chain operation (i.e. "edge of the network")?

The edge of the network in this case refers to either the node
performing the exchange, i.e., straddling both blockchains by having
channels in both, and the endpoint creating the route, i.e., the
sender of the transfer. These are the only ones who need to concern
themselves with the problems that come from this being a cross-chain
transfer. There may be some added noise for other nodes when it comes
to being able to prove things along routes, e.g., "here's proof that
the next hop is misbehaving" if we don't understand the proof since it
is in a blockchain we don't know. But since the node straddling the
chains is already providing the exchange service it can simply
increase its margin to compensate for these cases.

It is far more efficient then to have them communicate out of band by
creating an order book on top of the base network and do order
matching in there, rather than attempting to fit this added complexity
into LN itself.

> >Moreover, there are two general problems with random currencies on
> >lightning. Firstly, it's not clear why you'd want them once bitcoin has
> >lightning: why use a highway to nowhere (unless you have invested money
> >in nowhere, of course).
> 
> I suppose that would be a good reason to want altcoin on LN....

While I understand the interest in LN as a decentralized and trustless
exchange, I think our primary goal is to create a payment network, and
accomodating the cross-chain needs brings in a lot of complexity into
an already complex system, with the need to translate all parameters
into Bitcoin equivalent terms (CLTV, amount, off-chain fees, on-chain
fees, ...). So I'm also rather hesitant to consider them now, while we
haven't gotten the base network off the ground in the simple one chain
scenario. Like Rusty I'd like to punt this to a future version of the
protocol.

> >Secondly, we've made several assumptions that
> >it's not free to create channels, which punts many DoS problems to the
> >underlying blockchain. If you can create free channels, this protection
> >vanishes.
> 
> By "free", do you refer to the fact, that most altcoins have low or
> practically 0 transaction fees?

Yes, many of the DoS deterrents require Bitcoin-like on-chain fees to
work at all. As I mentioned above we might push the risk onto the
nodes straddling the chains, but how attractive would their service be
if they need to charge high fees to absorb that risk?


I'd like to apologize for braking so much with the ideas you have come
up, I just wanted to make it clear that we are currently focusing on
slowing down the evolution of the 1.0 spec, so that we can finalize
our implementations and start integration testing. It should not
dissuade you from bringing them up, and I'd encourage discussion on
the ML, as long as it is understood that it likely won't be part of
the the 1.0 spec ;-)

Cheers,
Christian