"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