Bitcoin: A Peer-to-Peer Electronic Cash System
As you said, any two parties are able to open (and close) a channel. However, these actions require an on chain transaction, and your funds are locked until you close the channel. Unless you're going to be exchanging many transactions in a short period of time with your peer, you would be better off creating transactions directly on chain.
I won't get into this here, but the lightning 'network' has its own set of scaling problems, which imo are much worse than that of the bitcoin network itself.
It's not technically a payment at that point, since the payments is atomic end to end. But yes, you send a message your peer, which sends it to another peer, which sends it to another peer...
like any other P2P network.
"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution." [1]
Furthermore, the previous title was "Electronic Cash Without a Trusted Third Party" [2]. So reading "Peer-to-Peer" as "Person-to-Person" would mean that the title hasn't changed in meaning, it just became a bit more catchy.
Also, when analysing the incentives of participants in the bitcoin network, it turns out that network nodes do not actually form the ideal-typical p2p mesh network (where all nodes are equally distributed and connect to a few other nodes) but a more densely connected network where connectivity to mining nodes is strongly incentivised. This topic has been researched and discussed by Dr. Wright (See [3] for more information).
[1] https://bitco.in/bitcoin.pdf
[2] https://nakamotostudies.org/literature/ecash/
[3] https://nchain.com/en/blog/bitcoin-network-topology-small-wo...
Wrights comments on topology are technobabble and largely meaningless, so it's difficult to say something about them... however, to the extent that we can assign any meaning at all to them don't you notice that saying your transactions need to go through particular nodes sounds an awful lot like the property you're using to argue that lightning is not peer to peer?
Banks throwing away checks is not a problem. Bouncing checks are a fraud problem, which is why most everyone have moved on from using checks is many situations.
Lightning's solution is to just 'watch' everyone you do transactions with, which is a lazy, non-viable solution analagous to continuously watching an anonymous stranger's bank account when they write you a check.
It takes something that is, in human terms, relatively simple and makes it so convoluted that it's hard to even follow.
I read the Lightning paper and found it simple enough to understand (conceptually at least) how the channels are opened, updated, closed, and penalized. Of course the actual implementation is a more complicated and nuanced than what the paper covers.
The same volume without lightning would require blocks that were terabytes, which is obviously unworkable at the current state of technology.
A "black swan" event like a major lightning hub going down may force more channel closings than the network (as currently implemented) has time to process before time-out.
The LN simply does not work if the base layer is congested.
Because lightning is actually relatively scalable it doesn't broadcast every action to everyone.
https://blog.dshr.org/2020/01/bitcoins-lightning-network.htm...
See Bolt 7:
> Note that the htlc_maximum_msat field is static in the current protocol over the life of the channel: it is not designed to be indicative of real-time channel capacity in each direction, which would be both a massive data leak and uselessly spam the network
https://github.com/lightningnetwork/lightning-rfc/blob/maste...
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.
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.
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.
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.
Among the "Bitcoins", only Bitcoin Cash is keeping that dream alive.