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/a20a865ce40d40c8f942cf206a7cba96/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