[mathiasrw]

You have to pre-setup a connection to others that you know and hope they know someone that knows someone that has a connection to the person you are trying to buy from.

This is how the design of lightning network incentivises mega hubs that know most people. So if facebook made a big hub with all its users it would work smoothly.

Also: You can not receive payments if the computer/wallet that hosts your lightning node is not online. Not super smooth.

[nullc]

> and hope they know someone

The system has routing, and it turns out that it doesn't take much for the probability of a graph to be connected with low average diameter. See: The six degrees of kevin bacon.

If lightning doesn't work for a particular payment, you can simply make a payment without using it, potentially by splicing out funds from one of your channels.

Yes, Lightning has trade-offs. You have to be online (though there is ongoing research into changing that), and some moderately complex software had to be written to create it.

But in return you get get massive efficiency increases and instant irreversible payments.

For the transactions that it's intended, I think for these are pretty good trade-offs... though if you don't like them you're free to not use it.

[phillipsjk]

> though if you don't like them you're free to not use it.

No true: due to limited block space on the base-layer.

I am not convinced you get any efficiency increase with the LN: just more difficult capacity planning because everything is suddenly so hard to measure.

Sending a payment, whether on the first or second layer, will take a certain amount of: bandwidth, processing and storage.

Even if fewer nodes are involved with each transaction, the LN seems to rely on a lot of message passing; beyond what a simple broadcast on the base layer requires.

Even is we assume the processing and storage requirements are equal: it will be more expensive on the LN. On the base layer, your data is protected from Byzantine faults by having each node verify the transactions as they come in. With the LN, state is local to each node. That implies you need redundant hardware to protect against Byzantine faults. I have been migrating my machines to ECC RAM and redundant storage: it is not cheap. What I save on hardware costs by buying old servers I pay in extra power use.

The above paragraph did not even mention the capital requirements of maintaining a Lightning node.

[nullc]

> Even if fewer nodes are involved with each transaction, the LN seems to rely on a lot of message passing; beyond what a simple broadcast on the base layer requires.

Today sending a transaction communicates 10 messages for each of ~100k nodes in the network. Once its confirmed, that transaction will additionally be sent once to every new host to join the network, forever.

Lightning sends a couple of messages back and forth among the nodes directly involved in the transaction... maybe 4. (The average shortest path length is about 2.8 currently).

So the marginal communication cost for a transaction is literally hundreds of thousands times lower-- even ignoring the cost to future nodes joining the network-- and this advantage grows as the number of nodes increases.