I think it’s important that everyone who supports bitcoin be on the same page about how the Lightning Network works and why bitcoin’s future is still as bright as ever. This short read was written up by a buddy in a slack channel and I thought it was important to pass along. It’s easy reading for anyone! 10 minutes of your time and if you’re not fully educated on the Lighting Network basics..you will be!
https://medium.com/@melik_87377/lightning-network-enables-unicast-transactions-in-bitcoin-lightning-is-bitcoins-tcp-ip-stack-8ec1d42c14f5
https://medium.com/@melik_87377/lightning-network-enables-unicast-transactions-in-bitcoin-lightning-is-bitcoins-tcp-ip-stack-8ec1d42c14f5
Yes. And no. There is a huge difference between a payment system and a network system, and it is very important to understand this. The comparison with the TCP/IP stack is tempting, and from a pure engineering viewpoint, it looks like it. But this is a big misunderstanding of some very fundamental issues.
First of all, even though this sounds like blasphemy, one has to understand that bitcoin and bitcoin-like coins, are not a network, but a data set. This was already clear in Satoshi's writings in November 2008. All value in bitcoin, all meaning in bitcoin, resides in a data set. The network is simply a tool to access and build the data set, but the network as such, has no value. You can do what you want on the network, if it doesn't influence the data set, it has no meaning in bitcoin. That data set is the block chain. In bitcoin, a transaction doesn't have meaning if it is not included in the block chain.
So this is already a fundamental difference with the TCP/IP stack. There's no "underlying data set" in TCP/IP.
The next point to understand, is that bitcoin has a very specific rule to make sure there's only one agreed-upon data set: proof of work. This system has evolved in such a way, that there are a very limited number of entities that actually (can) MAKE this data set. There are many, many less entities that actually write in this data set, than there are users of the system. There are at most something like 20 entities that write the data set (of which 3 or 4 write more than half of it, 10 write about 99% of it). These few data set writing entities are in a competitive game that makes it necessary to have high-quality data links amongst them.
Users of the system (bitcoin users) need to consult very small pieces of the data set in order to know about their balance, and may need to ask one of these few "data set writing entities" to write something on their behalf into that data set: the first act is verifying one got paid, the second act is paying (sending a transaction). Essentially, a user wants two things: know for sure he got paid and pay and see that he paid. That's all there is to know for a user.
As such, the three NETWORK functions that are necessary in bitcoin, are:
1) users need to be able to send transactions to the "data set writing entities". That's a communication from 1 to something like 20 entities. The users can pay.
2) the 20 entities writing the data set should make that data set at disposal of the users. That's classical one-to-many serving: the users can verify they got paid, or they paid.
3) the 20 entities writing the data set should of course also communicate between them in their competitive game which results in the data set expansion.
The first function is a very limited multicast. This is something akin to sending an e-mail to 20 destinations.
The second function is like a very classical web server: put data at disposal for users
The third function is like a backbone high performance link.
Right now, there is a P2P grid of nodes that performs the first and the second function, which is far from optimal. There's a P2P network that takes care of the communication between the user and the data set producers, transmitting transactions from the users to the data set producers, and caching/proxying the data set to serve it to users. So network-wise, it is as if there were no ISP, but we all connected our PC to our neighbours, and we are accessing servers through our PCs.
It is the misunderstanding of this, not seeing that it is essentially client/multi-server structure, which is at the origin of the claims of unscalability. This system scales perfectly, and it was already described by Satoshi in November 2008.
Proof of work splits the system in a small set of competing servers/data builders, and a large set of users. The difference between this system, and a classical client-server system is essentially simply that the "server" is a "multi-server" of a relatively small number of entities. Instead of 1, there's something like 20, but with 10 you cover already 99% and with 3, you cover 50%.
In such a system, you could, even though it is somewhat clumsy, forget about the bitcoin network. You could have these 20 entities, still connected by a high-performance back bone, and having set up some FTP server of the data set (preferentially, something somewhat more sophisticated, that allows searching and only downloading parts: an SPV kind of server). You could send your transactions by e-mail to some, or all of these entities. That would work too. People who want, could download the full block chain from some of these FTP servers. Some would only download the header chain. Some only one block. Some only one transaction, a Merkle tree, and the full header.
Bitcoin would work just as well, and there's no need for a P2P network.
This is why the 'base layer' in bitcoin is not a network layer.
Comes now the LN network. The LN network is also not comparable to a TCP/IP kind of routing protocol, for two reasons, both due to the "locking in of funds in a channel". In a communications network, you can set up and break links at essentially no cost, and once a channel is set up, you can send as much data in one direction as you want. You can open many links simultaneously. With the LN network, however, "opening a socket" is a costly operation, and opening a socket limits your ability to open another one: funds locked into one socket, are not available any more for another one. In as much as "setting up a TCP link" was essentially risk-free, "setting up an LN channel" stops you from setting up another one with the same funds. If you see that your link is "dead", you will have to wait for a day or a week to be able to set up another one and it will cost you a fee. Next, TCP connections can be used to send data in one direction, or in both. With LN channels, you can exhaust all intermediate links. There's only so much that can go in one direction. In other words, the LN network is not comparable to the flexibility of TCP AT ALL.
For a payment system, this is actually quite problematic, because the essence of a payment system is that "money goes round in circles". If there's one thing the LN cannot do, that is to make money go in circles. The LN network can only make money "oscillate" back and forth. But going around in circles exhausts all links along the circle. However, where this is interesting, is in trading. Trading is indeed "going back and forth". So in as much as the LN network is quite a bad "money transporter", it can be a good "high frequency trading system". An electrical engineer would say that the LN network is "AC coupled". You cannot push a DC stream through it, but you can push oscillations through it. In fact, the only way in which the LN network can "make money go round in circles" is if all users in the circle are connected to the same central hub.
So this analogy breaks down entirely. Bitcoin is not a network but a data set, and bitcoin's functioning is not "broadcast", but client/multi-server in reality. There is not really a scalability problem in a client/multiserver architecture, as we know. Moreover, this doesn't form a basis of a network. And the LN network is way, way, way less flexible than the TCP layer.
The scaling problems in bitcoin find their origin in not understanding (or not wanting to understand) the real data flows in bitcoin and the real nature of the system.
