"Will the Lightning Network really bring enough scaling?"
"Is such a solution computationally better than a block size increase?"
Yes and yes!
The Lightning Network completely changes the scaling game.
It changes it because now we can start talking about millions and millions of transactions per second,
which you can't even conceive of with a block size increase.
A block size increase can push the can down the road, but you don't change scaling by orders of magnitude...
with block size increases.
It's not possible to do without fundamentally destroying the decentralisation principles of Bitcoin.
At least, not yet.
Whereas with Lightning, by taking most of these transactions off-chain [until settlement],
[we retain] the exact same trust model while doing actual bitcoin transactions with smart contracts.
Lightning is Bitcoin; it's me exchanging signed bitcoin transactions with another person,
without reporting them on the blockchain [until later].
We don't need to unless there is a dispute.
We can do millions of those [payments] per second just between the two of us,
let alone everybody else in the world.
Yes, the Lightning Network really does bring enough scaling.
It allows us to change the dimensions of Bitcoin.
It allows us to reduce the granularity of payments, not just down to millibits but even
down to satoshis and sub-satoshi amounts -- which has been demonstrated, by the way.
We can do that on the scale of millisecond round-trips,
basically creating and confirming transactions thousands of times per second.
Anonymous asks, "How dangerous would it before the average user to run a Lightning Network hub...
on a home PC or a smartphone?"
[First of all], there is no such thing as a "hub."
The Lightning Network is a collection of peers.
If you only open one channel and you don't want to route payments, you're not really
using the Lightning Network [as it was intended].
You should be using Lightning in a bi-directional fashion, where you're also routing payments.
It gives you much more privacy.
If you're only connected to [one other Lightning node], then it can see all of the transactions...
coming from you and it knows you're not connected to anybody else.
It can tell that the transactions are yours.
If you're connected to [more than one other node], the transactions could be coming from
any number of routes in which you are one hop.
It's not possible for any of the nodes to know whether you're the originator or simply relaying.
Everybody relaying everything is the model, in a mesh network and not a 'hub-and-spoke' system.
It is the better and more secure model.
It is what the clients implement right now.
[The client] will automatically connect to lots of nodes to give you that mesh connectivity.
"Is it dangerous for an average user to run that?"
I don't know. I don't know what you mean by "dangerous."
There is some security risk in that it is a live system that will have keys on it [and therefore is] a hot wallet.
If you're running that hot wallet with a lot of bitcoin in it, then it is a target for attack.
Someone could hack into your Lightning node and use it to make an [unauthorised] payment,
to drain your wallet.
That's the security risk.
There may also be legal risk, but I'm not a lawyer so I can't really comment on that.
Different countries, different jurisdictions, different states will have different requirements.
I would assume that if you do run a Lightning node, you should be running it over the Tor network.
Again, I don't know.
It depends on the state of the rule of law in your jurisdiction or country.
"Do you think second-layer solutions to scaling make hard forks on the first layer exponentially
harder to do?"
Hmm... that's a really interesting question.
I hadn't really thought about that.
Well, they do in some way.
For example, if you have bitcoin tied up in a multi-sig as part of a Lightning channel,
and someone hard-forks that, being able to use the new fork on that amount of money...
in the payment channel would require you to have support for [the new fork] in the Lightning client...
that you're using so it can move those with a non-replayable...
Yeah, a second layer does make it harder to do, to be beneficial to those who hold [bitcoin in channels].
It makes it hard for the airdrop to be successful.
Interesting concepts.
I hadn't really thought about that.
Thank you, Andre.
"Is the Lightning Network really viable?
How surmountable are Lightning's scaling challenges?
Some Bcash supporters I follow on Twitter questioned the ability of Lightning nodes
to maintain the state of channels, fees, and balances well enough for the network to function well.
Thoughts?"
By the way, I'm not calling it Bcash.
I'm reading the question to you as it was [written].
Ron has been reading some postings from BCH supporters who are criticising Lightning as
'unable to scale.'
One of the criticisms I've heard myself, seen in a number of videos and Medium posts,
is the idea that routing on the Lightning Network is not a solved problem.
That's absolutely right!
Routing is not a solved problem in the Lightning Network.
In fact, Lightning is still under heavy development and in the very early stages.
Most of the clients are still in the beta category; they're pre-production software.
Even though you can run Lightning on mainnet, it's still not really suitable for production use.
There are bugs to iron out.
What about Lightning's routing?
The bottom line is that routing is not part of the core specification of Lightning.
That's deliberate.
The reason for that is because the routing algorithm is independent of the construction
of payment channels.
There are two broad considerations in Lightning: how do you construct payment channels between
two parties that do not require trust, and how do you transmit payments by connecting
a number of payment channels together to create a [routing] path?
That's one set of problems which is specified by a series of standards called the BOLT standards.
In fact, there are three different types of Lightning Network that are defined by three different standards.
There is Basics of Lightning Technology (BOLT), one set of standards, around which there are
a number of implementations.
There's Lit, a slightly different implementation of payment channels and routing,
and then there's Raiden, which you may have heard of, on the Ethereum network.
These are other implementations of the same concept but with a different set of specifications.
I'll talk about BOLT, which I think is what most people refer to today as the Lightning Network.
BOLT is the set of standards that allow interoperability between the three most common implementations:
c-lightning, LND, and Eclair.
These three implementations are currently interoperating with a very big network...
that is growing rather rapidly on mainnet, and testing out the basic concept.
Routing at the moment on that network, is done in a very simplistic fashion.
That's a mechanism called source routing.
The interesting thing about the Lightning specification is that routing is not part of [the specification].
It can be handled separately.
Like many other inter-networks, which is what the Lightning Network is, a network of networks,
routing is something that happens in a separate layer of the protocol.
There can be multiple independent routing algorithms operating simultaneously.
You may have heard of another inter-network that has routing as a separate layer,
where many routing algorithms operate independently.
That is the internet, of course!
In the very early days of the internet, when the network was small and fairly static,
the mechanism used for routing was called source routing.
Each host kept a broad map of what the network looked like and constructed paths for the packets...
by encapsulating that path within each packet.
The source of a transmission on the TCP/IP network in the very early days incorporated
information into the packet that said, "Send it to this node, then have that node send it...
to the next node, and that node to the next node, etc."
That path was specified in advance.
The Lightning Network uses source routing for now.
The reason for that is because it is one of the simplest implementations you can have.
There are some criticisms that source routing won't scale, and that's absolutely right.
Source routing will not scale.
But the Lightning Network isn't committed to using just source routing.
There are a number of other routing algorithms that could be used.
In fact, many could be used simultaneously on the network to optimise for different things.
Maybe [there would be] a routing algorithm that optimises for privacy, fees, minimum amount...
of hops to reach a destination, large payments, or small payments.
Who knows? This is still an area of active research.
There are two or three proposed routing implementations that...
use different structures within the network, in order to introduce some level of hierarchical routing,
where you have nodes that are aware of their immediate environment
i.e. nodes that are most closely connected to them.
Then they aggregate that information and act as beacons that repeat it to adjacent "neighborhoods."
This organisation of Lightning into neighborhoods, with nodes repeating that information...
across neighborhoods, is one proposed approach to routing.
There will be dozens more, just like today on the internet there are dozens of routing protocols
operating for different levels of scale and uses of the network.
The routing that's used to route IP packets on back-hall fibre optic networks is different...
from the routing that is used within your office block to route packets within a switched environment.
That's how it should be.
When people ask "how surmountable are Lightning's scaling challenges, is it viable, does the routing scale,"
that to me is a matter of engineering optimisation.
It is naive to say at this stage that, because the source routing we have today doesn't scale
to billions of nodes, no routing can ever scale to billions of nodes without centralising the network,
creating a hub-and-spoke system, or destroying privacy.
To say that it is not possible because it is not being done today, is to misunderstand
how engineering works.
I think this is an area of active research.
The routing algorithm that exists today works for the Lightning Network that exists today.
One of the key tenants of engineering is that you don't optimise something...
before it is necessary to optimise something.
Premature optimisation is a bad engineering practice.
There's no reason to introduce, or waste resources on trying to build, a routing algorithm that
scales to millions or billions of nodes today when we only have thousands of nodes.
There are other more interesting engineering problems to solve at this point.
I would argue that issues of user interface design and [user experience] are far more important
to solve at this stage of the Lightning Network.
Solving problems of routing at scale will happen when it needs to happen.
Not yet.
"Is the Lightning Network really viable?"
Yes, it is. It works today.
I think there is far more research and development than most people realise is happening in this exciting space.