From decker.christian at gmail.com Tue May 9 09:56:20 2017 From: decker.christian at gmail.com (Christian Decker) Date: Tue, 9 May 2017 11:56:20 +0200 Subject: [Lightning-dev] Channel top-up In-Reply-To: References: <20170504103930.GA27668@nex> <20170504175329.GA4125@nex> Message-ID: <20170509095620.GB21968@nex> On Fri, May 05, 2017 at 06:00:40AM -0400, ZmnSCPxj wrote: > Potentially, another application for onion routes with on-chain and > off-chain hops is for exchanges. > > Suppose I initially have 1000 BTC but only 0 LTC. Since I can afford > it, most of my 1000 BTC is in an LN node, slowly gaining more money > from routing fees. > > But, with 0 LTC, I can't initiate connections on the LTC side of the > network. I can pay to Litecoin users, but I would have to make some > out-of-band request for a Litecoin-side LN node to connect a > Litecoin channel to me. > > One way for me to gain LTC would be to route from my BTC LN node, to > a BTC/LTC exchange node, and request the final hop to go to an LTC > address I control via an on-chain HTLC transaction. > > After that, I can initiate LTC connections to LTC LN nodes directly > myself, without going through an exchange each time, or > alternatively hodl my LTC. > > This would allow anyone to be a cross-currency exchange, without > having problems about chicken-and-egg problems like "how do I > receive LTC via Lightning if I don't have LTC to initiate a channel > on the LTC side". Of course, in reality, cross-currency exchanges > already exist, so maybe this is not a problem in practice. Yes, there is a possibility for doing atomic cross chain swaps using Lightning nodes, and routing in a circle back to ourself, starting with the outgoing currency and ending in the desired currency. The fact that we can directly perform the first hop on-chain, as you pointed out, is a great way of having other nodes connect to us and doing an initial balancing of the capacity, e.g., initially they'd own 100% of the channel, but with the conditional on-chain transfer they'd send us some. > Now, we can argue that we can add an "invitation to connect to me" > to make a channel that is set up to send money to me. This helps > also the new-business-node case (where Alice is setting up a > business and wants to initiate receive channels, rather than the > default send channels). > > But what is the reason why channel opens, in current 1.0 spec, > require the initiator to be the one, and the only one, to put up > funding for the channel? It's just simpler, since it requires very little coordination, having multi-party funded channels is definitely on the roadmap, but with your insight above we can already balance the channels right from the get go. > My understanding (it's not explicitly stated in the paper, or in the > rfc specs I've read) is that the initiator pays for the fees in > setting up the channel. > > If we have an "invitation to connect to me" request, and people > comply with the request, the fees come from their funding of the > channels. If I spam the network with this request, then I will waste > everyone's time making those channels, locking up their funds, and > wasting their transaction fees. If I then don't open up a channel to > anyone else and I don't do some service for which I get paid, then > the channels set up to me are wasted in routing gossip, since no > route can pass through me, as there is no way to move money out of > my node. > > Instead, we can keep the "initiator pays for full funding of channel > open" and not have an "invitation to connect to me" request. Then I > can initiate a channel with a well-connected counterparty (paid for > by me), request a route through the new channel, to my counterparty, > and ending with an on-chain hop back to an address I control. This > effectively reverses the direction of the channel, and because I > have money in the channel, my counterparty can add the tx fees for > the on-chain hop to the routing fees he would charge for this onion > route, paid for from my initially sending-direction channel. > > So I think, basically, that allowing onion routes to start and end > on-chain is an elegant way to modify channel states to what we want, > while ensuring that everyone is reasonably protected from bad actors > on the LN. > > Of course, there is some risk. If I make a request to make a route > to a node, and have that route end up to, say,1.0 BTC to an on-chain > public key I control, and that node accepts, I know that node has at > least 1.0 BTC in spare funds, and I might use this information to > assess if I want to hack that node's operator's computer. Well, at the latest when the channel is being funded you'd see that information anyway. Also he could fund only part of the amount you provided and instead give you a partial refund if it can't afford to open a channel with the capacity you requested (though we may have to tweak the script of the on-chain tx to ensure the refund has precedence). As mentioned above, the ability to treat on-chain payments like any other lightning channel transfer is very nice. It allows us to treat the on-chain payments identically to off-chain payments (with the caveat of confirmation times), so we can extend all our Lightning schemes with on-chain hops :-) Cheers, Christian