From ZmnSCPxj at protonmail.com Wed May 24 23:54:42 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 24 May 2017 19:54:42 -0400 Subject: [Lightning-dev] Generalizing proportional routing fees to exchange rates In-Reply-To: <20170524104319.GA6483@nex> References: <8737bw2mgu.fsf@rustcorp.com.au> <20170524104319.GA6483@nex> Message-ID: >> >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. Ah, so my understanding, this is some variant of LN or a layer on top of LN which basically has some extensions, and that this will be for some future development. >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. I understand. >> >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. I understand. >> >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 understand. It is very interesting to me to consider about how incentives work out in this situation, and I shall study further. >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 ;-) There is no need to apologize, I understand completely. I am studying now the components needed to make Lightning Network work, and I shall continue to ask. A quick question. Is it possible to (at least theoretically) create an LN node software that is effectively SPV? From my current understanding of current LN software, it seems most of them require some Bitcoin core full or pruning node, or integrates such functionality. Perhaps, lit appears to use SPV, though I have not delved much into the code, so I suppose my understanding is correct. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: