In this article we will take a look at the necessity of the Lightning Network for Bitcoin regarding the use case of fast payments. The basics of the layer 2 technology will be explained starting with its fundamental requirements and the characteristics of payment channels to the point of the design of the whole network. Besides to that, there are alternative Bitcoin scaling solutions.

For the past few years, the transactions per second (tps) processed by the network have been mostly between 3 to 4 tps. In comparison to that, Visa claims carrying out more than 65,000 tps. Although many people state that the real purpose of the main layer of Bitcoin is the assurance of the security of the whole system by verifying its integrity according to the protocol. The time-consuming process of transacting value roughly every ten minutes is necessary to keep the growth of the blockchain small. Therefore, it is cheap, running an own node so that numerous clients can participate and increase the decentralization of the network. Despite that, fast transactions are indispensable for a broad utilization of the cryptocurrency and could lead to a main use case concerning daily payments without the absence of the underlying safety.

Therefore, in 2016 the whitepaper of the Bitcoin Lightning Network was published, which seeks the solution of this issue by applying off-chain payment channels on the second layer and transacting bitcoin across this network. Especially micropayments are supposed to be applied with this concept, due to almost no fees.

In order to create these channels and therefore build the Lightning Network, a few mechanisms of Bitcoin are necessary, which will be explained subsequently.

The five Pillars enabling the Lightning Network

1. Unconfirmed Transactions

The confirmation of transactions by including them into a block, propagating it to other nodes through the network and coming to an agreement using the proof of work consensus mechanism is the part of Bitcoin that slows down the whole process. By merely exchanging transactions without confirming them at first, this execution can be accelerated. The local storage makes it possible that each participant can broadcast the transaction to the network at any time and therefore settle the current state of the channel.

2. Double-Spend Protection

The Lightning Network is built on multiple transactions, that refer to the same unspent transaction output. Eventually only one can be broadcasted in order to settle the funds. Similar to the Bitcoin network, this protection is necessary as a solution of the double-spend problem.

3. Multi Signature Transactions (multisig)

This more complex pubkey script type is primarily being implemented by another standard script called “pay to script hash” (P2SH). Transactions are being sent to a hash of a redeem script that can contain multiple signatures required to spend the funds. The Lightning Network makes use of 2-of-2 multisig addresses for the creation of payment channels.

4. Time-Locks

Blockchains in general are encapsulated systems, that face a difficulty in receiving information from the real world or transmitting it vice versa. The handling of accurate time for example would require a service — such as an oracle — to collect that information. Due to the recurring production of blocks at ten-minute intervals on average, time can be displayed using the block time.

Time in the context of transactions is essential in Bitcoin because funds can be deposited for a specific time on the main layer and therefore be used in payment channels on the Lightning Network. There are two different versions of locking bitcoin up that only differ in the way they address time. CheckLockTimeVerify (CLTV) locks bitcoin up until a given block height is reached. CheckSequenceVerify (CSV) works with relative time and applies a number of blocks that need to be produced from the moment the transaction is created, until the funds can be spent.

5. Hash Values and Secrets

Hash functions are one of the fundamental cryptographic features, the Bitcoin network is making use of. They serve as a test because the input (secret) of the hash function cannot be deciphered, even if the output (hash value) is given, whilst the creation of the output is effortless if the input is known — therefore they are called one-way functions. This can be used for locking bitcoin up again. Anyone who knows the secret that produces the hash value will be able to spend the funds.

A simplified View: Bidirectional Payment Channels

The Lightning Network consists of multiple bidirectional payment channels that represent a linked system where nodes can reach each other through a couple of hubs. For the comprehension of the whole system, the flow of a single payment channel is mandatory.

In our example we will take a look at Alice and Bob that want to create a channel together and exchange bitcoin in various off-chain transactions. The first transaction is the opening of the channel. Each participant can choose whether or not to fund the 2-of-2 multisig address and what amount they will transact. However, this procedure contains the risk of one party leaving the channel immediately after its creation. This could occur in particular, if only one party (Alice) sends funds to the channel and the other (Bob) disappears. In that case Alice’ funds would be trapped in the channel, where the signature of Bob remains missing. To solve this issue, Alice creates an initial commitment transaction that would send the amount back to her and makes Bob sign this transaction. Thereby this pre-signed transaction can be broadcasted by Alice after the disappearance of Bob in order to get her funds back. After this additional step, the channel can be opened.

In our example each one of Alice and Bob will transact one bitcoin to a multisig address. As explained above, they will first create an initial commitment transaction by their own that will send the funds deposited back to each party and makes the other one sign that one. So, Alice creates a transaction that will send one bitcoin to Bob and one bitcoin to herself and signs it. Bob on the other hand creates a mirrored version of that. His transaction — signed by him — would send one bitcoin to Alice and one bitcoin to himself. Finally, they exchange the pre-signed unconfirmed transactions, which leads to the following result:

Afterwards they sign the funding transaction and deposit their bitcoin. From there on, the deposited bitcoin can only be spent, if both signatures are being provided.

If one party leaves the channel now, the other one could use the pre-signed initial commitment transaction, sign it by their own and broadcast it, to get back the funds they deposited into the 2-of-2 multisig address.

The next step is the first exchange of bitcoin between Alice and Bob. In our case Alice will send 0.1 bitcoin to Bob. Therefore, the previous commitment transactions have to be updated. As each party keeps track of their own transactions, they will again create mirrored versions of the updates. Alice would send 1.1 bitcoin to Bob and 0.9 bitcoin to herself. Bob respectively creates a transaction that would send 0.9 bitcoin to Alice and 1.1 bitcoin to himself. Each one signs their own transaction and send it to the other party. It seems rational that either Alice or Bob could now broadcast the latest transaction and send themselves the entitlement of bitcoin.

But what prevents (especially) Alice from broadcasting the initial commitment transactions where she would receive one bitcoin once again?

This is where the Lightning Network makes use of hash values and secrets, which were discussed earlier. For a substantial comprehension, we will take a look at the initial commitment transaction of each party once again, which consists of additional features. At first each party creates an individual secret and sends the hash value of that to the other person. Next, there is another output option included to the initial commitment transaction, which allows the person naming the secret of the other one to receive all the funds deposited in the payment channel. This option exists in order to punish the other party in case of a malicious behavior. At last, the person broadcasting the transaction has to wait for 1000 confirmations to redeem the funds. These features prevent the broadcasting of older versions. Again, each party signs their own transaction and sends it to the other one. The following illustration visualizes the structure:

With the updating of the channel and the creation of another couple of commitment transactions, each party reveals the first secret and gives it to the other person. In addition, Alice and Bob individually create a second secret and exchange the hashed version of it for the protection of further transactions. This is an ongoing process for each prospective commitment transaction. The previous secret is being revealed and a new one is being created. Alice and Bob each sign their own transaction and exchange it with each other.

If Alice still attempts to cheat and broadcasts the initial commitment transaction, giving her one bitcoin, she will immediately send one bitcoin to Bob and now has to wait for 1000 confirmations to redeem her funds so that the fraud is successful. Meanwhile, Bob can include the secret of Alice, which he has received in the updated commitment transaction, and punish her by redeeming all funds.

Since Alice and Bob want to continue exchanging bitcoin, the transactions need not to be broadcasted, which would lead to the channel being closed. This is the magic of the Lightning Network. The main layer will only see an opening and a closing transaction. In the meantime, there could have been an unlimited number of off-chain transactions, that the network is unaware of. This enhances privacy and enables the exchange of bitcoin at small fees.

The Lightning Network: Payments through multiple Channels

In this section we introduce Carol. She has an open payment channel with Bob. Alice wants to send some funds to Carol. Because opening a new channel to every person she would send bitcoin to is expensive and inconvenient, the Lightning Network enables routing of transactions through multiple payment channels. Consequently, a network of nodes is being constructed, where every party is indirectly connected to each other through a couple of hubs.

In our example Alice wants to send 0.2 bitcoin to Carol, routing that payment through Bob, because he maintains open channels to both.

It is important to keep in mind, that this is still an untrusted environment. So, if Alice pays Bob, what assures that Bob will send the amount to Carol?

The solution to this issue is making use of Hash Time-Locked Contracts (HTLCs). Carol, who has the incentive to receive the funds, creates a random value by her own, without revealing it to the other participants at first. Instead, she hashes the value and gives it to Alice, who sets up the first commitment transaction which Bob can reproduce and create the commitment transaction with Carol. To make use of that hashed value, we add another output option to each commitment transaction which claims 0.2 bitcoin from the payee’s capacity of each channel. This output contains three paths. The first one is similar to the protection we already used in case one party broadcasts an obsolete transaction. The second path refunds the bitcoin to the payee after a specific time elapsed. This is also the period, the receiving party can take, to apply path three. Regarding Alice and Bobs channel, that third path will send the 0.2 bitcoin to Bob, if he provides a value that — when being hashed — corresponds to the hash value, that Carol spread. The same output option is included respectively in the commitment transactions of Bob and Carol. The exchange of secrets and hashed secrets has been neglected in the following illustration:

A few details need to be addressed according to the HTLCs above. The contracts are being set up from left to right, whilst the temporarily deposited funds are being collected from right to left. Therefore, Bob needs to be protected, so that the elapsed time for collecting the funds is descending, giving him time to claim his bitcoin. Otherwise, he would be trapped with a worthless value he received from Carol, since Alice has already withdrawn her funds. In the illustration above, Bob could claim his bitcoin after three days if Carol has not yet provided the value. There is a one-day difference until Alice can withdraw her funds. Further, there are small fees that the routing nodes receive for providing capital. This fee is comparatively low to transactions on the main layer.

Closing the Channel

Finally, payment channels that are no longer needed can be closed again. This usually occurs, because one party of the channel needs the liquidity contained therein. Since Alice and Bob each have a pre-signed and unconfirmed commitment transaction, they can sign and broadcast it individually at any time and settle it on the main layer. This would result in a miner including the transaction in a block. The party that broadcasted the transaction would have to wait another 1000 confirmations to access the funds, whilst the other person can use them immediately. This is the previous protection in case an older commitment transaction has been published. Alice and Bob could also close the channel collectively, by creating and signing a 2-of-2 multisig transaction with the last state of the payment channel. This will overwrite all previous states and again settle the agreement on the main layer. Both parties would have access to their funds immediately after the transactions has been settled.

Final Thoughts

This article outlined the basic function of the Lightning Network. It is the second layer of the Bitcoin network that is supposed to increase its scalability and improve usability. Due to the instantaneous settlement of transactions, payments can be made within a few seconds. Therefore, the Lightning Network can be seen as a peer-to-peer alternative to the payment solutions of Visa and Mastercard. In 2021, its adoption increased vastly. New node operators entered the community, who established further payment channels and provided more liquidity to the network.

When writing about bitcoin being deposited into payment channels on the Lightning Network, this article deliberately avoided referring to “locked bitcoin”. This perspective was shared by the Lightning Network developer and researcher René Pickhardt who is also co-author of the book named “Mastering the Lightning Network”. In a podcast he emphasized that he is using the expression of “bitcoin being released”, when speaking about funds that are deposited into a payment channel of the Lightning Network. This is since bitcoin being processed on the main layer are very rigid and expensive, as the validation of transactions takes a lot of time and block space is limited. However, fast and inexpensive transactions can be processed in real time via the Lightning Network, giving the funds greater usability.

Author: Marvin Blaich

A central issue for the rare use of cryptocurrencies in everyday commerce is their volatility, that characterizes most of the tokens. As an investment vehicle this seems beneficial, but if you buy groceries, you assume that your shopping cart will contain as many items today as well as tomorrow. Thus, you need to make use of a medium of exchange, that keeps your purchasing power relatively stable. To achieve this stability, known stablecoin protocols depend on specific mechanisms which can be classified into three categories: Reserve-based (e.g. Tether), collateral-based (e.g. Dai) and algorithmic-based, which applies to Basis Cash.

Protocol design of Basis Cash

Basis Cash is a stablecoin that is characterized as open-source and permissionless with an “algorithmic central bank” that represents a mechanism which keeps the value of the token stable. This occurs similar to central banks managing the price stability of fiat currencies — by regulating the number of tokens circulating.

The stabilization mechanism of the protocol is primarily realized by the three different tokens in the network and their particular functions and correlation:

· Basis Cash (BAC) is the stablecoin that serves as a medium of exchange. As earlier addressed, this would be the token, you buy your groceries with. It is, unlike most stablecoins, only indirectly connected to the US-Dollar, due to a direct peg to the Dai token (DAI).

· Basis Bonds (BAB) is the instrument, that regulates the value of BAC by increasing or decreasing the quantity of tokens in circulation. BAB can be purchased and redeemed at any time and have no expiration date. The exchange rate between BAC and BAB is 1:1.

· Basis Share (BAS) is the governance token that rewards its holders with newly minted BAC in case of an increase of demand (seigniorage).

Stabilization mechanism

The aimed value of one BAC is $1. A price oracle is reading the time-weighted average exchange rate of BAC-DAI every 24 hours from the Uniswap v2 contract to keep the value stable. Stabilization in the Basis Cash protocol is defined as a spread (1±ε). Therefore, we can identify three different situations and how the protocol mechanism responds to them:

· Price > 1+ε: If the price rises due to a higher demand of BAC, the conclusion would be, to increase the quantity of tokens in circulation (expansionary policy). This occurs by issuing newly minted BAC. The holders of BAB could therefore redeem their bonds in order to receive the BAC, that are issued. If there is a positive deviation, means there have been minted more BAC than BAB redemptions, the remaining tokens will be distributed to the holders of shares (BAS). In case of a negative deviation, not all bondholders could redeem their BAB.

· Price = 1±ε: Due to a price that is located in the aimed spread for the exchange rate of BAC-DAI, the protocol mechanism will not react.

· Price < 1-ε: As mentioned above, BAB can be purchased at any time and have a priority claim, when new BAC-tokens are being issued. When the price is trading below the given spread, this implies an incentive to all participants to buy the bonds. The BAC which are being used for that exchange, will be burned. Accordingly, the quantity of tokens in circulation is decreasing and the price will shift back into the spread zone (contractionary policy).

Why does the peg fail?

The described stabilization mechanism of Basis Cash seems to be simple, but why is it, that the aimed spread cannot be reached?

The stabilization and proper functionality depend on the participants in the network. If there are many investors that are attached to the system, the price of BAC is relatively stable, and the mechanisms can adjust the slight divergence to the aimed spread.

When investors start to trade their BAC for other tokens and withdraw their money from the system, that causes a decrease of the price due to a higher supply of BAC. According to the stabilization mechanism, the remaining investors would be incentivized to buy BAB. If that does not occur, the price will stay below the spread. More investors could withdraw their money because of a missing stabilization of the price. This will lead to a further degression and therefore to a vicious circle, as long as investors are leaving the network.

BAC as a predecessor of TerraUST (UST)

In May 2022 the the algorithmic stablecoin UST of the Terra blockchain led to the crash of one of the biggest ecosystems. The stabilization mechanism of UST was similar to BAC. The token guaranteeing the stability on the Terra blockchain was LUNA, which corresponds to BAB regarding Basis Cash. If the price of UST dropped below $1, arbitrageurs could buy one UST to the current price and convert it to $1 worth of LUNA. By that, the UST is being burned and LUNA is minted. The consequence would be a decrease of the quantity of UST in circulation, which pushes the price of each token back to $1. If the price of one UST is above the peg, arbitrageurs can buy and convert $1 worth of LUNA to $1 worth of UST. Whilst the LUNA token is burned, the UST is being newly minted. This increases the supply of UST and reduces the price to guarantee the peg.

Similar to BAC, the stability mechanism of UST works, as long as there is trust in the algorithmic design. Due to several incidents, the selling pressure on UST increased in May, which means that in total there was more value being offered than there was demand for it. This led to a death spiral. Users emitted their UST by redeeming it for LUNA and sold it. The huge supply of LUNA on the market was increased even more due to the minting of new LUNA for each redemption. In consequence the price decreased, and the project collapsed.

Final thoughts

Finally, it can be stated that algorithmic stablecoins suffer from a bad reputation. Despite sophisticated concepts, even before the collapse of Terra Luna, there were protocols that could not fulfill the promise of stability. For this reason, the collapse was not unexpected. It is unclear whether other algorithmic stablecoins will be developed in the future and if they will establish successfully.