Hi Christian, Are there any open source simulators available for trying different routing strategies? Or even a simulator for the Lightning network as a whole?
Regards sarva On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker < decker.christ...@gmail.com> wrote: > Oh yeah, my mail tool destroyed that mail quite expertly :-) > > The footnotes were > [1] https://github.com/lightningnetwork/lightning- > rfc/blob/master/07-routing-gossip.md > [2] https://medium.com/@rusty_lightning/lightning-routing- > rough-background-dbac930abbad > [3] https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba > 96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf > > We will eventually move away from the hash function based approach in > favor of something that allows us to decorrelate hops in a route. We have > indeed started writing down some of the ideas at least for Lightning in the > project's wiki [4], but they're definitely not fleshed out. > > [4] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming > > > On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <b...@mord.io> wrote: > >> "I think this is exactly the right venue to discuss these kinds of >> issue..." - you are probably right! My bad. >> >> Christian, thank you for your knowledgable reply. The footnotes did not >> come through on my end, I am especially interested in [3]. Do you have a >> link? I am thrilled to hear of a Bitcoin-compatible revive alternative! :) >> >> Are we keeping an inventory somewhere of the cryptographic primitives >> being used in lightning and the specific assumptions being made about them >> (e.g. preimage resistance vs collision resistance and such)? One project I >> have not yet found but believe we need across the entire cryptocurrency >> community, is a (wiki-style?) inventory of unproven mathematical >> assumptions (e.g. hardness of discrete logarithm) and/or cryptographic >> primitives, cataloged in terms of the cryptocurrency technologies which >> require them. Such a resource could help the community respond more >> quickly, comprehensively, and transparently to the inevitable cryptanalytic >> surprises that will pop up over time (especially from the quantum >> cryptanalytic area, but even the classical cryptanalytic community as well). >> >> Related, I believe the ideal end state would be to only assume existence >> of a preimage-resistant hash function, and to code such that one function >> could be quickly swapped with another and thus update entire system. I'm >> not sure if that is a realistic goal, but here is my first attempt to move >> in that direction in case it is of interest to lightning. It is hard to >> imagine it would be a new idea, although I have not yet found the precedent: >> http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html >> >> Thanks, >> Ben >> >> >> On Nov 17, 2017 8:04 AM, "Christian Decker" <decker.christ...@gmail.com> >> wrote: >> >> On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <b...@mord.io> wrote: >> >>> Ivan, >>> >>> That is mostly false, but with bits of truth sprinkled in. Contact me at >>> b...@mord.io for further discussion so we tread lightly on the lists' >>> email inboxes. >>> >> >> I think this is exactly the right venue to discuss these kinds of issue, >> so please don't move the conversation somewhere else :-) >> >> Routing is still very much in flux, we have a minimally viable routing >> protocol in the spec [1]. It is minimal in the sense that we just push >> the entire network's topology to the edges, which can then locally >> compute routes. This is effectively a source-routed network, which >> matches the requirements of the onion routing protocol we use for >> privact as well. But this does not mean that this is protocol is set in >> stone. We are actively working on finding better solutions to the >> problem of finding routes across a vast network of millions if not >> billions of nodes. Distance vector routing such as BGP uses may be one >> option like Ben suggested. >> >> For now the network can easily scale to about 1 million channels [2] >> even on very limited devices, Upgrading to another protocol at a later >> point in time is trivial, since none of the routing information is >> consensus critical. We have all the extension points built in to allow >> future extensibility. >> >> >>> But briefly: scale-capable routing protocols are possible as >>> demonstrated by IP and thus by the internet itself. As for centralizing >>> flow through small number of liquidity providers, yes that does seem >>> economically probable, at least unless / until off-chain channel >>> rebalancing mechanism (like the recently proposed "revive" protocol) come >>> about. Bitcoin script is not currently revive-capable but Ethereum is, so >>> either Bitcoin revive could be enabled via two-way pegged sidechain >>> protocol with Ethereum, or even better, by a purpose-built (yet still not >>> Turing-complete) extension to Bitcoin script itself in the future. >>> >> >> As a matter of fact, Conrad and I just published a similar technique for >> off-chain channel rebalancing and fund re-allocation based solely on >> Bitcoin [3] (major props to Conrad for the excellent writeup!). The >> flexibility in Bitcoin exists. >> >> As for the hubs everybody is assuming will form, I don't think they're >> as likely to form. Creating such a hub is extremely costly since it'll >> have to allocate sufficient funds to cover the maximum imbalance of all >> of its channels ahead of time. Then the fees must cover the opportunity >> cost of allocating all of those funds to channels instead of investing >> them somewhere else. On top of that the funds will not be moved alot >> since they serve only a small number of endpoints connected through >> those channels, this compounds the problem of having high fees. The high >> fees make the hub channels a really bad choice for your payments, after >> all you were looking for small fees for your payments, right? It opens >> up an opportunity for nodes to open bypasses that grab some of the >> traffic and associated fees from the expensive hub. >> >> All of that being said, we should be careful about our predictions on >> how the topology will look, I added some counter arguments to a >> hub-and-spoke network forming, but nobody can really be sure about >> what'll happen. >> >> >>> In either case the lightning network seems a key first step, and even >>> were off-chain payment rebalancing not possible for some odd reason, the >>> lightning network seems extremely valuable and scaleable - regardless >>> because the centralization you speak is not one that affects safety of the >>> money supply itself, and these centralized hubs would be more dispensable / >>> swappable versus the mining centralization risk that people more often talk >>> about in Bitcoin. Lightning network centralization, even if it persisted >>> somehow despite revive and future concepts, would not be an existential >>> risk. >>> >> >> Rebalancing is definitely possible, even without [3], you can >> disincentivize the use of a channel until they have been rebalanced. For >> long term imbalance, opening another channel may be the best option >> >> >>> As for transaction fees, the idea is only channel setup / tear down are >>> required greatly reducing fees. Yes if txin fees were millions of dollars >>> then people could not practically penalize fraud, but that is unlikely. >>> Even if txin fees made fraud claims marginally unprofitable (yet practical) >>> that would still be ok - the judicial systems of most countries prove that >>> people go beyond self-interest when sufficiently ticked, a fact of human >>> psychology which in turn creates the incentives that support honest >>> business. (Also please be aware I'm not a lightning code contributor, so >>> that team might also be doing more to address already than I thought to >>> mention above.) >>> >> >> This is open to speculation as well. We hope to reduce the load on the >> on-chain network sufficiently to allow timely on-chain settlements. By >> aggregating payments off-chain we can also aggregate the fees and then >> use them to pay on-chain fees. So don't consider the on-chain fees for >> your channels as your sole loss, they are paid for by payments you >> forward. Ultimately this should encourage participants to open channels >> that support the network as a whole, not just themselves. We are >> building automations that should take care of this, the user won't have >> to do anything to improve the network topology. >> >> Cheers, >> Christian >> >> >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
