From ZmnSCPxj at protonmail.com Fri May 5 10:00:40 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 05 May 2017 06:00:40 -0400 Subject: [Lightning-dev] Channel top-up In-Reply-To: References: <20170504103930.GA27668@nex> <20170504175329.GA4125@nex> Message-ID: Good morning again, >That's very clever, I like the combination of on-chain and off-chain >payments. I still like my splicing approach better (yes, I'm pretty >biased in this case ^^) but being able to combine on-chain and >off-chain is a great feature, let's see how far we can push it. 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. -- 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? 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. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: