What is Lightning Protocol? Blockchain Scaling Solutions

What is  lightning Protocol  + Raiden? Blockchain Scaling Solutions guide.

Bitcoin and Ethereum are getting more and more popular, there is no denying that. This is a graph of the number of daily bitcoin transactions tracked over the years:

Image Courtesy: Wikipedia

And here we have the number of ethereum transactions per month over the years:

Image Courtesy: Etherscan

What is lightning Protocol? Blockchain Scaling Solutions

While this is a great sign and shows how cryptocurrencies are becoming widely used and accepted, there is a big problem that has reared its ugly head in recent times. Because of the sudden increase in the number of transactions, both Bitcoin and ethereum are facing severe scalability issues.

The scalability issues stem from the way the open ledger system is designed. Suppose Alice has to send 1 BTC to Bob, how will the process work? Alice can’t physically give Bob the money, bitcoin is digital after all. The way the transaction will take place is simple:

• Alice declares that she wants to send 1 BTC to Bob and send the transaction details to the miners.
• The miners verify that it is indeed Alice sending the request and no one else and they consequently approve the transaction by putting it in the blocks that they have mined.
• Bob gets the 1 BTC.

So, what is the problem in this whole sequence?

The miners become a bottleneck for the entire transaction.

The fact is that the miners simply can’t keep up as the number of transactions keeps on increasing. There is pretty much a backlog which happens as a result of transactions not getting verified fast enough.

Plus, there is also the small matter of transaction fees. Whenever miners mine a block, they become temporary dictators of that block. What that means is that they can charge a nominal “transaction fee” in order to insert transaction data into their blocks. However, in order to get their transactions done faster, and to jump the queue so to speak, people can pay higher transaction fees to incentivize the miners into verifying their transactions first.

Unfortunately, this leads to a big problem.

Normal bitcoin users who pay the normal transaction fees, more often than not need to wait a long time to have their transactions approved. In fact, let’s see how much time would one have to wait, on an average, if they paid the least possible transaction fees.

Image courtesy: Business Insider.

If you pay the lowest possible transaction fees, then you will have to wait for a median time of 13 mins for your transaction to go through. 13 mins! More often than not, the transactions had to wait until a new block was mined (which is 10 mins in bitcoin), because the older blocks would fill up with transactions.

Now things are looking pretty bleak when it comes to bitcoin. Let’s see how things are looking in Ethereum’s corner.

Theoretically speaking, ethereum is supposed to process 1000 transactions per second. However, in practice, ethereum is limited by 6.7 million gas limit on each block.

Image Courtesy: Hackernoon

Since each block has a gas limit, the miners can only add transactions whose gas requirements add up to something which is equal to or less than the gas limit of the block.

Image courtesy: Hackernoon

This, once again, provides a bottleneck on the number of transactions that can go through per block.

ethereum was managing only 20 transactions per second while Bitcoin was trudging along at 7. When you compare this with the fact that Paypal manages 193 transactions per second and visa does 1667 per second, you could see w0hy there was a big problem and why this needed to be solved fast.

One way that bitcoin is solving its scalability issue is via Segwit and block size increase. However, in this article, we will be focusing on two very interesting proposals which can not only solve the scalability problems, but it can, in fact, enable 1000s of transaction per second. They are:

• Lightning Protocol (Bitcoin).
• Raiden Network (Ethereum).

What is Lighting Protocol? + Raiden

Before we get into these two, there are some things that need to be addressed.

A state channel is a two-way communication channel between participants which enable them to conduct interactions, which would normally occur on the blockchain, off the blockchain. What this will do is that it will decrease transaction time exponentially since you are no longer dependent on a third party like a miner to valid your transaction.

So what are the requirements to do an off-chain state channel?

• A segment of the blockchain state is locked via multi-signature or some sort of smart contract, which is agreed upon by a set of participants.
• The participants interact with each other by signing transactions among each other without submitting anything to the miners.
• The entire transaction set is then added to the blockchain.

The state channels can be closed at a point which is predetermined by the participants according to Slock.it founder Stephan Thual. It could either be:

• Time lapsed eg. the participants can agree to open a state channel and close it after 2 hours.
• It could be based on the total amount of transactions done eg. close the chain after $100 worth of transactions have taken place.

Image Courtesy: Stephan Tual Medium Article

So, in the image above. We have a car which directly interacts with the charger and does a total of $39.19 worth of transactions. Finally, after a series of interactions, the entire transaction chunk is added to the blockchain. Imagine how much time it would have taken if they had to run every single transaction through the blockchain!

A payment channel is basically a state channel which deals exclusively with payments and micropayments between parties. Remember, all the interactions on the channels are things that could happen on the blockchain but are happening off it. There are several kinds of payment channel designs, let’s go through some of the more popular ones.

One of the earliest examples of the payment channel was suggested by Satoshi Nakamoto himself.

This system uses some interesting features:

• Transaction Replacement.
• Input sequence numbers (nSequence).
• nLocktime.

“nLocktime” is basically the parameter which defines the time before which the transaction couldn’t be accepted into the block. The concept is pretty simple. There is a value called “UINT_MAX” and the nSequence cannot exceed that number. So suppose there is an unconfirmed transaction and one can keep changing that before putting it in the block before the time “nLocktime” runs out OR nSequence becomes equal to “UINT_MAX”. For each replacement, the sequence number becomes higher.

However, there were a lot of security issues with this and was never properly executed.

Before we continue there are two things that we need to note.

Firstly, we would like to give David A Harding a shoutout for the explanation of Spillman-Style and CLTV-Style Payment Channels.

Secondly, before we continue, you need to know what a multi-sig P2SH address means.

When it comes to addresses in bitcoin, there are two kinds:

• P2PKH address aka Pay-to-PubKey Hash address.
• P2SH address aka Pay-to-Script Hash address.

A “normal” Bitcoin address looks like this: “15fXdTyFL1p53qQ8NkrjBqPUbPWvWmZ3G9”. This is a normal P2PKH address. In order to spend the bitcoins sent to this address, one has to simply decrypt using the corresponding private key and get access.

However, a Bitcoin can have more versatile spending conditions attached to it than that. You can create much more than simple P2PKH transactions. People realised that early on and they started playing around with the “scriptPubKey” in Bitcoin’s Script Language.

What is the scriptPubKey?

This is what a simple 1 input and 1 output transaction looks like:

Image Courtesy: Bitcoin wiki

The “scriptPubKey” in the “output” above basically dictates the spending conditions. You can basically add your own lines of code to the scriptPubKey and define the spending condition yourself. The core developers foresaw this happening and to prevent spenders from putting in long lines of code in the conditions, they enabled them to just put in hashes of their conditions instead. These conditions are called redeem script. In a P2SH transaction the scriptPubKey only contains the hash of the redeem script. The script itself is only revealed and verified during the pending transaction.

Now, because of this, a very important thing happens. Because the script verification happens only during the spending transaction, it removes the responsibility of providing the full redeem script from the sender to the receiver. This, in turn, gives a lot of advantages:

• A sender can send money to any multisig transaction without knowing the full details of the transaction. This helps a lot in abstraction. More often than not, whenever you spend money, you rarely care about what is going to happen to your money after you have handed it over. The same logic is used here as well.
• It is much simpler for senders to send money to short and well-defined hashes aka script hash instead of long and confusing scripts.

So that is a general explanation of what a mutisig P2SH address is. An address that pays to a script hash” instead of a public address. Now let’s go back to our examples of payment channels.

This style of payment channels was described in the bitcoin development mailing list and was implemented in “bitcoinj”. The Spillman-Style uses two separate transactions, the deposit and the refund. So, let’s look at the process:

• Alice (the merchant) gives her public key to her customer aka Bob.
• Bob uses his public key and Alice’s public key to create a multisig p2sh address which will require signatures from both Alice and Bob to spend any funds paid to that address.
• Bob create a transaction but does not transmit it. He uses that transaction to pay the multisig address. This transaction is the deposit.
• Bob now creates a second transaction which is the same as before and uses that to overwrite the previous transaction. As a result of this the first one goes back to Bob’s address. Bob then declares a timelock on the second transaction to make sure that it doesn’t get inside the block before a specific amount of time and signs it.
• Bob gives this second transaction to Alice who then proceeds to sign it and return it to Bob. Remember, Alice still hasn’t seen the Deposit transaction i.e. the first transaction yet.
• Now, Bob has a transaction which has been signed by both him and Alice and acts as a refund. So if Alice, the merchant, doesn’t a do a particular job before the timelock runs out, Bob can claim the refund transaction for himself.
• Now that the refund has been signed off on by all the parties present, Bob can safely declare his deposit transaction and add it to the blockchain.

While the Spillman-Style was useful to create a payment channel which would keep the merchants honest, it was still susceptible to malleability. When the deposit transaction is broadcasted by Bob, it needs to be byte-for-byte same as the refund transaction. If it isn’t the refund transaction is no longer valid.

In order to solve this issues, CLTV-Style Payment channels were implemented post BIP 65. Let’s see how it works:

• Alice (The Merchant) gives her public key to Bob (the customer).
• Bob uses his public key and Alice’s to make a P2SH address using the following conditions:Condition 1: Both Alice and Bob sign on any transaction that happens through this address.Condition 2: Only Bob can sign of any transaction on his own but those transactions must have a lock time greater than the refund deposit.
• Bob immediately creates a deposit transaction and broadcasts it on the blockchain. Because of condition 2 above, he is assured of the fact that he can pretty much generate a refund on demand.

• Now remember, the first condition states that the Alice and Bob both need to sign on any transaction that happens in the P2SH address. So, Bob (the customer) can sign his part of the transaction and Alice can sign her part without revealing her signature details to Bob. By doing this Alice can broadcast the final payment to the blockchain before the refund can get broadcasted.

The biggest advantage that this method has over Spillman-Style is the removal of malleability that can affect it. In the Spillman style, Bob was bottlenecked by the fact that he needed to broadcast a deposit which matched the refund byte for byte. He basically needed to pre-commit which he doesn’t need to do anymore. These channels use the “OP_CLTV opcode” which was enabled thanks to BIP 65.

Hashed timelock contracts or “HTLCs” are one of the most convenient applications of the payment channels. In fact, the Lightning Protocol is an implementation of the HTLC. So, what is an HTLC? Till now we have seen channels which use “timelocks”. An HTLC “extends” that by introducing “Hashlocks” along with the timelocks.

The HTLC enables opening up of payment channels where funds can get transferred between parties prior to a pre-agreed deadline. These payments get acknowledged via the submission of cryptographic proofs. Along with that, another brilliant feature of the HTLCs is that it allows a party to forfeit the payment given to them and return it to the payer. On top of that, payments can be made across channels as well.

Plus, there is another amazing feature that comes in thanks to the HTLC. It makes cross chain transactions possible. This is called atomic cross chain trading and enables users to exchange a part of cryptocurrency on one chain (eg. bitcoin on the main blockchain) for a part of cryptocurrency on another chain (bitcoin on a sidechain).

Alright, so how does the HTLC work?

Imagine Alice has to send some funds to Charlie via Bob.

• Alice opens a channel with Bob and Bob opens a channel with Charlie.
• Suppose Alice declares that she wants to interact with Charlie.
• Charlie declares a random number and generates its SHA256 hash and hands it to Alice. Basically, if Charlie chooses a number A then he will give the hash of the number H(A).
• Alice sends 0.1 BTC to Bob with the condition that only someone who can submit the data required to get the same hash can retrieve the payment. In order for Bob to misuse the funds he will need to have the data aka the pre-image required to generate that hash. Basically, Bob will have to give “A” which he doesn’t have.
• Bob now hands over the funds to Charlie using the same condition. Charlie finalizes the payment from Bob by handing him over the pre-image “A”.
• Bob finalizes the payment from Alice by handing her “A”.

The lightning network is an off-chain, HTLC style, micropayment system which is deigned to make transactions work faster in the blockchain.  It was conceptualized by Joseph Poon and Tadge Dryja in their white paper which aimed to solve the block size limit and the transaction delay issues. It operates on top of Bitcoin and is often referred to as “Layer 2”.

As Jimmy Song notes in his medium article:

“The Lightning Network works by creating a double-signed transaction. That is, we have a new check that requires both parties to sign for it to be valid. The check specifies how much is being sent from one party to another. As new micro-payments are made from one party to the other, the amount on the check is changed and both parties sign the result.”

So, let’s checkout some of the features that are coming in thanks to the lightning network:

• Fast payments: Payments are almost instantaneous.
• Not dependent on miners: Transactions don’t need to be approved and verified by miners for it to go through.
• Micropayment friendly: Earlier micropayments were extremely inconvenient on the bitcoin blockchain. Now they are possible thanks to the lightning network.
• Multi-signature friendly: The transactions will go through if and only if everyone present in the channel approve.
• Reduces blockchain load: With so many transactions happening of the chain, it greatly reduces the load that the main chain has to take.
• Decreases waiting time: Since the transactions are happening off chain and without miner intervention, there is little to no waiting time.
• Helps in scalability since it will increase the number of transactions happening per second.

As amazing as the lightning network is, there was one major obstacle in front of it that needed to be managed. The lightning network, as with all payment channel methods is susceptible to transaction malleability.

Before we understand what transaction malleability is, it is important to recap one of the most important functions in the cryptoeconomics model…hashing. We have written an article before which covers hashing in detail. Just to give you a brief overview, a hashing function can take in any input of any length but the output it gives is always of a fixed length.

However, there is one another important function of hashing that you need to know to understand the “transaction malleability bug” as it is called. Any small change in the input data will drastically change the output hash.

Eg. Checkout this test that we did with SHA-256 aka the hashing algorithm used in bitcoin:

This is a test

C7BE1ED902FB8DD4D48997C6452F5D7E509FBCDBE2808B16BCF4EDCE4C07D14E

this is a test

2E99758548972A8E8822AD47FA1017FF72F06F3FF6A016851F45C398732BC50C

See that?

We just changed “T” from uppercase to lowercase, and look at what it did to the output!

One more thing that you need to understand about the blockchain is that it is immutable, meaning, once the data has been inserted in a block, it can never ever be changed. While this proves a safety net against corruption, there was one weakness that nobody saw coming.

What if, the data was tampered with

it even entered the block? Even if people found out about it later on, there was nothing that anyone can do about it because data once entered in a block can never be taken out! That, in essence, is why malleability of transactions is such a problem.

Now, why does transaction malleability happen?

Every bitcoin transaction has an input data and an output data.

Let’s see the input data in particular:

Image courtesy: djp3 youtube channel.

It consists of the number of transaction inputs taken and the signature data. The signature data causes two problems:

• It is extremely bulky and takes a lot of space.
• It can be manipulated and hence cause transaction malleability.

In fact, signature data manipulation can make it seem like the transaction didn’t even happen in the first place. Let’s see this in an example.

Suppose Bob wants Alice to send him 3 BTC. Alice initiates a 3 BTC transaction to Bob’s public address and then sends it over to the miners for approval. While the transaction is waiting in the queue, Bob uses transaction malleability to alter Alice’s signature and change the transaction ID.

Now there is a chance that this tampered transaction will be approved before Alice’s gets approved, which in turn overwrites Alice’s transaction. When Bob gets his 3 BTC, he can simply tell Alice that he didn’t get the 3 BTC that she owed him. Alice will then see that her transaction didn’t go through and will them resend it. As a result, Bob will end up with 6 BTC instead of 3 BTC.

So, let’s get this straight. Can malleability permanently destroy lightning protocols? No it can’t. However, it can make the entire experience very slow and annoying. Malleated transactions will get stuck at various steps in the channel. The only way that this can get resolved permanently is by introducing trust in the system or by setting highly inconvenient timeouts. There are a lot of reasons why this is undesirable:

• The timeouts can become annoying.
• Any system that is built on trust is corruptible. That’s the fundamental philosophy behind bitcoin, to build a system that is completely trustless. A system that can keep itself honest without depending on the trust of individual humans is the perfect system.

So, to move forward and truly scale up with lightning, a fix was needed for the malleability issue and that fix came in the form of Segwit.

Segwit aka segregated witness had a very simple concept. If most of the problems were arising from the signature data in the blocks, why can’t we just pick it up and keep it in a parallel side chain? Basically, put in all the transaction minus the signature data in the main chain and put all the signature data in a side chain.

This is what a block would look like post segwit:

So by removing the signature data from the transactions, it was killing two birds with one stone, the block space got emptier and the transactions became malleable free. With one fell swoop Segwit solved the malleability issue and paved the way for seamless lightning network integration.

Ethereum’s version of the lightning protocol is called Raiden. In ethereum 20 transactions happen per second. To speed things up and enable faster transactions of Ether and ERC20 tokens, the Raiden network is being introduced which will act pretty much like the lightning protocol and enable fast transactions in private channels.

While the full-blown Raiden network may not get completely ready yet, the fact is that many people just need Raiden for many-one payment functionalities. So for them, micro Raiden (µRaiden) has been created which enables easy and a fast micropayment structures.

The thing is that Ethereum is largely impractical for instantaneous transactions. There is a long waiting line for transactions to be added to the various blocks in the blockchain and more often than not, you will have to pay huge fees to cut the line. What the Raiden network is going to do is that it will help people in the network make instantaneous payments via payment channels.

Raiden will be structured like a mesh type structure running on top of the ethereum main chain:

Image Courtesy: Hacked.com

Raiden was conceptualized by Brainbot technology. This is what founder and CEO Heiko Hees had to say about Raiden:

“Basically all blockchain based applications that want to scale to real world usage will benefit from Raiden. It can be used for applications like asset trading in gaming or finance, retail payments, micropayments for content (think the next YouTube or Spotify where creators are directly paid for every second consumed). But it’s also suitable as an infrastructure for cheaper, faster and more secure correspondent banking.”

So, how does Raiden work?

Suppose Alice and Bob want to interact with each other using Raiden. This is how they will go about it

• Alice and Bob open a payment channel between them which will be off chain and they deploy a smart contract.
• Both parties make a security deposit in the smart contract.
• Suppose Alice wants to send 3 tokens to Bob, she signs the message “3” and sends it to Bob. Bob now has proof of Alice sending him 3 tokens.
• Now, suppose Alice wants to send Bob 4 more tokens. She will update the state of the message to “7”. This shows that the message is conveying the previous and the latest transaction as well.
• The moment Bob wants to redeem the 7 tokens, he will go the blockchain and close the channel. He will get the 7 tokens from the deposit that was initially made in the channel.
• The information will be relayed to the blockchain and the only record that will be stored is the final 7 token deposit made to Bob.

Raiden is going to have an ICO to fund for its setting up process. During the ICO, investors will get their hands on the Raiden token RDN. What is the use of this token? The design of the Raiden Network is such that it will inevitably cost fees. Part of the network is such that people will have to sit and observe their channels to make sure that none of the fun is stolen. However, instead of sitting on their computers and seeing their funds all day, they could simply outsource this work to someone and pay them by RDN.

What are some features of the Raiden Network?

• Usable and simple application programming interface (API).
• Enables ethereum scalability.
• Can be operated by an ERC20 token.
• Enables fast and simple transfer of money.
• Will decrease the load on the ethereum blockchain.

For blockchains to scale up they absolutely must have off chain solutions. Payment channels are one of the best methods to go about it. If Bitcoin and ethereum can nail Lightning and Raiden, then the possibilities are endless. Imagine having thousands of transactions per second whilst paying negligible transaction fees and having the ability to trade and connect with other blockchains? All that isn’t a pipe dream anymore. We can’t wait to see how it pans out!