The Future of Bitcoin Scalability: An Introduce to Lightning Network and Alternatives (LBTC&BCH).
Abstract
A problem which may loom ahead many of us is that to conduct On-Chain scalability on Bitcoin POW is always to compromise the extent of decentralization. Thus, some efforts are being tried out on the scalability in an Off-Chain approach to tackle such problems as the poor processing capability and high handling fees of Bitcoin transactions. Lightning Network, by building a payment channel based on cryptographic algorithms, enables on-chain resources only to be consumed when the channel is established or closed, where both parties can conduct any number of transactions with free of charge.
This paper introduces two basic transaction modes of Lightning Network — RSMC and HTLC, and explains why Lightning Network, as a platform of Off-Chain scalability, can also achieve the same level trustless-ness as On-Chain transactions.
In fact, we have to admit, however, the infrastructure needed for the Lightning Network is still lacking, and the cost of maintaining the payment channel remains constantly high, making it extremely likely that the Lightning Network will generate large-scale specialized financial institutions in its development, just like those banks we see today. But conversely, these rather centralized institutions are exactly what Bitcoin is fighting against and trying to replace from the very beginning. It is for this reason that Lightning Networks has also sparked heated debate among Bitcoin supporters.
Lightning Bitcoin or LBTC as a forked version of Bitcoin has blazed a new trial to solving the problems in Bitcoin scalability. It achieves great scalability in an innovative way that combines DPOS consensus mechanism with the original Bitcoin-UTXO Model. This design, though to some extent inevitably compromises the level of decentralization relative to the Bitcoin-style POW, has really stricken a balance between working efficiency and system robustness.
LBTC believes that expanding block capacity on the basis of Bitcoin POW mechanism (e.g. BCH) will generate but miserly amount of marginal benefits while instead may entail serious potential hazards. The Off-Chain scalability (e.g. Lightning Network), however, may again send the Bitcoin ecosystem back to its traditional track dominated by centralized intermediaries. As far as the Bitcoin scalability issue is concerned to this point, the Off-Chain approach represented by Lightning Network and the On-Chain one represented by LBTC may be two of the most promising solutions to the problem at our discussion.
1. The Scalability Issue of Bitcoin
1.1 Problems in TPS and Handling fees of Bitcoin Transactions
Bitcoin blocks size is fixed at 2M and can generate one block about every 10 minutes. Following this, let’s first calculate the Bitcoin TPS:
TPS(BTC)
= Block Size / TX Size / (10 * 60)
= 2 * 1024 * 1024 / 500 / (10 * 60)
≈ 7
It’s now clear to us that Bitcoin can in average handle about seven transactions per second. Plus, as the number of people using Bitcoin increases, Bitcoin transactions will definitely surge, which is very likely to cause transaction congestion. When this congestion does occur, those to-be-processed transactions will be queued in a waiting order while causing problems for users.
What is more, transaction congestion may bring about another dire consequence, namely a surge in transaction fees. We know that Bitcoin transactions are packaged by miners, who are paid by mining rewards and transaction fees, so they always remain incentivized to raise the transaction fees they are to receive. Thankfully, the situation that users expect to pay lower fees while miners chasing after higher fees paid will see the market running in a balanced state with acceptable fee levels maintained. However, if transaction congestion occurs, the balance between supply and demand in the market will be broken, and miners at this time can demand higher fees (because miners theoretically have the right to choose prioritized and packaged transactions).
Historical data (the above vertical axis represents the dollar-based transaction fee) show that the single Bitcoin transaction fee peaked at more than $50 at the end of 2017, staying at $15–20 for even the two months before and after the new year. But during periods of inactivity, transaction fees can be generally maintained between $0.3 and $1.50.
Though the “off-season” fees may seem to be acceptable, people cannot be satisfied with the status quo. After all, Bitcoin as a cryptocurrency is expected to move toward extensive applications and hence should be able to to deal with large-scale transactions. Because of this, the Scalability Problem of Bitcoin has been widely blamed by critics.
1.2 On-Chain Scalability of Bitcoin
As above mentioned, Bitcoin followers have indeed realized the seriousness and urgency of Bitcoin Scalability. But how? That’s the controversy trigger.
The first is the On-Chain scalability. As the name implies, On-Chain Scalability, is to achieve higher TPS data by modifying the parameters of consensus protocol. For Bitcoin, of course, expanding the block time, increasing the block size and reducing the computational occupation of transactions are all theoretically feasible attempts. However, as a cryptocurrency system sharing the largest market value, any nuance of modification on Bitcoin could be so influential and far-reaching that we should be extremely cautious. The fact is in order to prevent the loss of decentralization caused by the high threshold of full nodes, it is almost impossible for Bitcoin to shorten the block time. Therefore, we have to shift our focus to block size and the computational occupation of transactions to find the way out.
In relation to the computational occupation of transactions, the Bitcoin framework has already determined the format and content of the transaction, leaving quite limited room for further reduction. Though the structure of the transaction has been somehow optimized after the SegWit upgrade, changes are still not impressive enough.
Eventually, we turn to block size. The initial Bitcoin protocol fixes the block size at 1M, which does not seem to pose any pressure to us in the era of rapid Internet infrastructure development. Some supporters standing with block size expansion suggested that block capacity limits be raised or lifted. In fact, however, this is what Bitcoin Cash (BCH), one of the forked versions of Bitcoin, has actually practiced. BCH has directly increased block size to 32M and claimed it will keep on increasing in the future. The upgrade of SegWit has also raised the Bitcoin block size to nearly 2M. While it is up for debate whether this idea of scalability is really viable since benefits generated after block size expansion are truly limited, but the damage to decentralization is rather marked.
Here we might as well make a simple comparison:
Bitcoin Cash (BCH) increases the block size to 32M, which can achieve a 16-fold TPS increase compared with Bitcoin (BTC).
Lightning Bitcoin (LBTC), through UTXO-based DPOS, can achieve TPS upgrade about 200 times as much as Bitcoin (BTC).
However, BCH while increasing the block size will also raise the threshold of full nodes and the efficiency and speed of block flow in P2P network. This is what concerns the vast majority of Bitcoin fundamentalists. It is right for this reason that Bitcoin (BTC) has to keep a really good watch on increasing block size and has always been reluctant to lift restrictions.
1.3 An Alternative Idea
Now that our gain from on-chain expansion is so limited and the potential damage so intimidating, what if we turn our attention to non-on-chain scalability?
The answer is definitely YES! We can address the Non-On-Chain scalability in two ways: the Off-Chain or the Cross-Chain.
Let’s first talk about the latter, Cross-Chain. Why “Cross”? Because it refers to binding stitched Bitcoin networks to a higher TPS blockchain to achieve substantially higher TPS. But to do so requires a well-recognized and viable cross-chain technology support and a Child Chain ecosystem solution. This is a bit embarrassing because we will have to introduce a brand new blockchain.
Now, the former. The Off-Chain scalability as a highly feasible solution to date concerns most of all. The famous Lightning Network is such a solution.
Off-Chain scalability means that transactions are done totally off the chain without occupying the on-chain resources. After a series of transactions are completed, the final result will then be transmitted onto chain. To put it easy, you can simply think of it as a small bank helping you with a series of transfer transactions. After transactions were finalized, data of balance will be regularly sent onto chain.
We will describe in more detail the operating mechanism of Lightning Network and assess whether this expansion is really effective or not in the following section.
2. Basic Operating Principle of Lightning Network
2.1 Payment channel
Many of us when exposed to Lightning Network may get a little confused and may ask: how can we trust the Lightning Network since it only deals with off-chain transactions?
Good question! If you ask so, it’s evident to me that at least you know something about the blockchain. Lightning Network does complete transactions in an off-chain approach, but I can assure you its operating mechanism is highly warrantable since Lightning Networks rely on a series of cryptographically secure solutions to do such things as payment channel establishment, payment and balance changes, and even node routing.
Here comes a new term: Payment Channel. It may sound a bit abstract, but you can understand it like this: it is an account opened and maintained between two payment parties. When a transaction occurs, it will be recorded into this account. After a period of time when several transactions were conducted, the balance of the account will be registered on the Bitcoin chain.
Lightning Network is such a payment channel network. In addition to the establishment and closure of payment channels to be finished in On-Chain transactions, the rest are all done off the chain. Based on this, Lightning Network achieves better off-chain scalability, greatly extending the trading potential of Bitcoin.
2.2 Payment Channel and RSMC Transaction
The opening, closure and balance change of payment channels are all realized through a transaction called RSMC.
RSMC or Revocable Sequence Maturity Contract, implies that contracts will become revocable when sequences expire. It achieves targeted functions by encompassing a series of transactions.
We now turn to illustrating the process of payment channel establishment by taking the transfer between Alice and Bob as an example.
Here is how the whole channel is established:
Step 1: Alice and Bob each take out their own BTC and build a Funding transaction. The input of this transaction is the exact BTC they are holding, and the output is a 2-of-2 multi-signature condition. The Funding transaction has not yet been signed by the two and not broadcasted at this time.
Step 2: Alice creates two Commitment transactions.
The input of the first transaction costs the Funding transaction where Bob signs his name (Alice not signed at this time). The transaction contains two output structures, the first one requires multiple signatures of both Alice and Bob (Alice2 indicates Alice’s another private key), and the second one needs Bob’s signature.
The second transaction is the first output pointing to the first transaction. It is first signed by Bob, whose output points to the address of Alice. This transaction has a Sequence condition, meaning that the transaction will become able to be packaged into the block only after the previous transaction has proved Sequence confirmation.
Step 3: Bob also creates two Commitment transactions, whose structure should be completely symmetrical with the those created by Alice.
Step 4: After having completed the above Commitment transaction setting, each party sign the Funding transaction and broadcast it.
A brief explanation is supplied here:
The purpose of the Funding transaction is to allow each party of payment to take out a certain amount of fund to establish a channel. The Commitment that follows makes it possible for both parties to unilaterally request a refund on it. In our illustration, both Alice and Bob are entitled to initiate a refund unilaterally. But it’s also noteworthy that who triggers the refund first will have to wait for a Sequence time before the other gets his/her refund instantly. Therefore, both Alice and Bob can cancel channels and terminate cooperation at any time, guaranteeing the safety of their funds.
2.3 Balance Update in Payment Channel
Now that Alice and Bob have created the payment channel, what else do they need if they want to perform transfer to each other?
Here is the to-do list: when they agree to initiate a transaction, they should first jointly establish another set of Commitment transaction in replace of the previous one, and then update the balance information in the transaction content.
But another problem pops up: the previous Commitment transaction is still there, and both parties have exchanged signatures. How can we discard it?
We do have a really ingenious solution. When the two parties create a new Commitment transaction, we require the signature of the initiator to correspond to a new private key (we might as well call it Alice3/Bob3). Under this circumstance, as long as Alice tells Bob about the her previous private key Alice2, Bob can modify the previous transaction into a new punitive transaction, whose output can be towards his/her own with the Sequence restriction removed. Then, if Alice signs the Commitment transaction privately, Bob could broadcast the modified transaction to perform punishment by causing her money loss. Thus, once Alice tells Bob about Alice2, she declares the previous Commitment transaction discarded. The same applies to Bob.
A little complicated, isn’t it? Don’t bother. Let’s come to the easy-to-understand conclusion: when the transaction balance needs to be updated, both parties can establish a new Commitment transaction to ensure that neither can unilaterally tamper with the fund balance in an attempt to make profits.
To this point, I believe your doubts have been largely solved. The establishment of related transactions can be achieved in constructing, closing and changing the payment channel balance even though both parties do not cost very much mutual trust on each other. Therefore, the Off-Chain payment channel can completely be Trustless.
3. Node Routing in Lightning Networks
3.1 Why the need?
The establishment of payment channel ensures that any two parties can create a set of Off-Chain accounts to record transaction balance changes and bring into realization transactions under the Trustless framework.
However, there is still a problem to be solved. We know that small-amount payment occurs very frequently with parties involved not always fixed. Does it mean that any two individuals must establish between them such payment channels anytime they need a payment or transfer? Absolutely not! As mentioned above, the establishment and closure of payment channels both are realized through On-Chain transactions. This will make the solution utterly no difference from On-Chain transactions if our Lightning Networks users will have to establish a payment channel with their counterparts before every payment. It is obviously absurd! So, in order to solve this problem, we need to build a Routing Mechanism between different payment channels.
Say, for instance, suppose Alice has established a payment channel with Bob, and Bob has also been sharing a payment channel with his friend Kevin. If Alice wants to transfer a fund to Kevin, Bob can now function as the escrow. No longer do we need to establish additional payment channels since the path “Alice→Bob→Kevin” can act to achieve payment behavior.
3.2 Payment Channel Routing and HTLC Transactions
HTLC or Hashed Time-lock Contract, as its name implies, refers to the contract locked by a hash value and an expiration parameter.
Bored and tired of these extremely complicated technical explanations? Here is another simple, real-life example.
In the example above, we have found a routing path of “Alice→Bob→Kevin”. Let’s continue by assuming Alice needing to pay Kevin 1 BTC.
First, Bob made a safe-deposit box, deposited 1BTC into it, and handed it to Kevin. Alice also did the same by making a similar box, depositing into the box 1BTC and handing it to Bob. The passwords for both boxes are the same, which need to be provided by Kevin. After Kevin had given the password, it will be open to anyone.
When the transaction is in process, Kevin opens Bob’s box and obtains the 1BTC by providing the password. After Bob knows the password, he can do the same to Alice’s box and get the other 1BTC.
We note that Bob actually served as an Escrow in this transaction, who enabled the Alice→Kevin transaction to be realized. So here, Bob theoretically stands reasonable to charge some commission as the reward for matching the transaction between the two. This of course can be easily fulfilled. For instance, he could only deposit 0.99BTC out of the 1BTC in his box, leaving the left 0.01BTC as his little commission for the transaction.
This metaphor may not be the case that will completely happen in real life but can roughly explain the principles of HTLC. As we see, HTLC is also Trustless. This means that we can set ourselves assured to support the high-frequency small-amount payments off the chain through a huge network of numerous RSMC and HTLC contracts without worrying about the safety of the funds.
4. Lightning Network VS. LBTC: Battle on Scalability
4.1 Some Comments on Lightning Network
It must be said that the Lightning Network is such a talented and successful idea, which is at least already on its way to large-scale implementation. The whole Bitcoin community is now keeping a close eye on the implementation of it, and the transactions within it have also proved vitality.
However, the current Lightning Network is still somewhere away from the large-scale applications on a real basis. There may also be several problems or aspects that are very concerning in Lightning Network:
1)Lightning Network sets very high the requirements for infrastructure. Since it locates itself as an ecosystem for high-frequency small-amount payments, there must be supporting equipment and software applications to support the algorithms required for the Network. But if you observe and examine the current situation carefully, you will find that the wallets that can support the Network are largely centralized ones, not really decentralized wallets. However, sending the decentralized wallets to the full and welcoming acceptance of ordinary users still has a long way to go. Against this backdrop, the meaning of the Lightning Network is easy to be questioned.
2) As an off-chain payment facility, the Lightning Network is far more demanding than its on-chain counterparts for intermediaries and both sides involved in transactions. It specifically requires an intermediary to operate online with both sides of transaction staying online as well to provide signatures and build RSMC and HTLC transactions. Such a model has posed challenges to intermediaries who utterly cannot survive if their capabilities are weak and scales are not large enough. Conversely, the on-chain transactions do not require so much for intermediaries and nodes where you even don’t have to worry too much since newly launched Bitcoin transactions will be just thrown into the P2P network waiting to be packaged and moving on to block generation.
Though we have gone through some weaknesses in regard to the Lightning Network, it must be noted that some of its shining virtues such as quick fund arrival and low commission must be recognized. Plus, thanks to the off-chain settlement of the Lightning Network, many other side merits like transaction privacy protection are also becoming accessible.
4.2 Deep into the Internal Conflicts of Lightning Network
The Lightning Network has indeed triggered much controversy, the most notable of which is it has re-encouraged centralized organizations, which, however, is what Bitcoin is from the very start standing against with.
As we have discussed before, the Lightning Network needs to rely on some intermediary nodes to match the counterparties inside the Network. These intermediaries (hereafter Hub) need to keep on providing online services constantly, meeting customers and matching them into transactions, maintaining a considerable number of payment channels, as well as reserving enough BTCs to address the mobility needs. When Lightning Network emerges, the entire Network will inevitably need some large-scale and excellent service Hubs to match transactions.
As a settlement center, Hub can even in the case of credit risk also provide financial services similar to those offered by traditional banks, such as providing advance payment, transaction settlement, temporary loans and even long-term mortgage services for institutional and individual customers. The only difference is it’s in the form of Bitcoin. In this process, Bitcoin has degenerated into a settlement tool in the Lightning Network, and gradually lost its asset attributes, just like the precious metals in today’s financial system.
More exaggeratively, the role of Hub in the allocation and settlement of Bitcoin and its huge volume of funds are likely to lead the regulatory authorities to imposing various constraints on the Hub. And these Hubs will someday gradually become highly professional and licensed financial institutions, and corresponding regulation sectors will also set high thresholds for businesses or individuals to run the Hubs. Also, it is possible for those large Hubs to be incorporated into the regulatory system in many ways, such as the liquidity of BTC asset holding, the statutory reserve ratio, the credit to customers and the term management of assets and liabilities, just as those banking domains supervised by the regulatory authorities.
So, what’s the difference between these Hubs and banks that Bitcoin creators from the very beginning put icy comments and cold stares on?
What is more terrible is that the Lightning Network may directly give birth to an online financial institution system with BTC as the settlement medium and deepen the impact of Escrow on BTC transactions especially when the currency attributes of Bitcoin are not so popular among the public. This actually will be rather overwhelming and frightening.
4.3 Lightning Bitcoin as another option for Bitcoin scalability?
As a humble supporter of Lightning Bitcoin (LBTC), it is necessary for me to introduce LBTC’s ideas on scalability.
With regard to the scalability issue, LBTC takes a quite offbeat approach: it does not attempt to solve the problem of high-frequency small-amount payments completely by relying on offline Escrow like what Lightning Network does, nor does it remain committed to improving TPS by expanding block capacity like BCH. LBTC believes that Off-Chain scalability is against the principle of decentralization, and the exclusive emphasis on expanding block capacity under POW mechanism is nothing but putting a band-aid on a stab wound.
BCH has relentlessly headed into expanding block capacity to improve TPS. This idea is of course theoretically feasible. But the marginal benefits of this increase are miserly low since when BCH increases block capacity by tens of times, the degree of decentralization will also be largely threatened.
Some POW fundamentalists may have the doubt that the UTXO-based DPOS mechanism adopted by LBTC is not decentralized enough. Let me just say that if the TPS of BCH can reach even a fraction of LBTC’s, its degree of decentration will certainly be reduced to somewhere even inferior to DPOS. And if BCH maintains the same degree of decentration as DPOS, its TPS will surly lag far behind that of LBTC.
The reason is the huge blocks are very difficult to circulate in the P2P network, which will make the POW mining ecology converge irreversibly and lead to the collapse of decentralization. If the network can afford to the increase of BTC from 1M to 2M, then further increase from 2M to 128M will almost put the entire ecology to the brink.
I’m not really having a go at BCH here. The value of BCH is that it has indeed integrated a considerable amount of computing power, on which it may also too much heavily rely. On the issue of substantial scalability, I believe that only Lightning Network and LBTC can enter into the field of play. But presumably each of them will succeed in their own fields.
4.4 If you are not familiar with LBTC…
This paper, in fact, is not intended for LBTC advertising (as I have claimed that I am a fan of it). After all, its visibility and popularity are far less than BCH and Lightning Network. But given the fact that many may be confused by the concepts of LBTC (Lightning Bitcoin) and Lightning Network, I still need to shortly brief on it here.
LBTC does have a similar name with Lightning Network, but it hasn’t got anything to do with it. According to the LBTC team, the name was originally used to demonstrate the fast confirmation speed of LBTC transactions and its vision of heading into high-frequency small-amount payment application scenario. So, try to avoid mixing the LBTC with the Lightning Network next time if you did get confused before.
LBTC has creatively adopted a UTXO-based DPOS. Its team thinks UTXO is highly robust, so it doesn’t want to let go of UTXO, the essence design of Bitcoin. The DPOS of LBTC has a fixed block time, about 3 seconds at present. LBTC believes that such consensus mechanism can not only maintain a certain degree of decentralization, but also can achieve high speed and efficiency that are totally beyond POW’s reach. Personally I believe LBTC can be put as a super-lite version of Bitcoin, and a UTXO-based DPOS is not that common. Interesting attempts.
Nakamoto has clearly defined in the Bitcoin white paper that Bitcoin is a peer-to-peer electronic cash system. The LBTC team believes that the best way to reach this vision is to strike a balance between efficiency and Bitcoin robustness to maximize the marginal benefits with efficiency significantly improved. That’s no bad idea. So, please excuse my making BCH as a counter example here. I’m just being as blunt as possible by convincing that it is not really a solution to the way of Bitcoin Scalability forward.
