Payment channels are a separate solution — called 2nd layer solution. This was possible to develop because the Bitcoin network has certains guarantees that allow applications to be built on top of it. Payment channels (Lightning Network for example) are one of the most popular. Some of the guarantees of the Bitcoin network that allow payment channels (and other blockchain applications) are:

Quorum of control : With multisignature constraints in scripts, the Bitcoin network ensures that there is a quorum to manage the funds controlled by multiple users.

: With multisignature constraints in scripts, the Bitcoin network ensures that there is a quorum to manage the funds controlled by multiple users. Timelock: This ensures that a script can only be executed before or after the specified time lock.

This ensures that a script can only be executed before or after the specified time lock. No double spending : One of the top fundamentals of this decentralized consensus algorithm, no UTXO can be spent twice

: One of the top fundamentals of this decentralized consensus algorithm, no UTXO can be spent twice Non-expiration : A valid transaction doesn’t expire, so it can wait forever until is picked to be added to the blockchain.

: A valid transaction doesn’t expire, so it can wait forever until is picked to be added to the blockchain. Censorship resistance : Anyone having the private key can spent an UTXO with no censorship of any kind.

: Anyone having the private key can spent an UTXO with no censorship of any kind. Authorization: By providing digital signatures the networks allow only authorized addresses to manage funds.

What are Payment Channels?

Payment channels are a trustless mechanism for exchanging bitcoin transactions between two parties outside of the bitcoin blockchain.

In short, they are mechanisms for underburdening the blockchain, by moving a lot of transactions out of the blockchain and into private routed channels between users but still counting on blockchain security.

Now let’s look at how State Channels work to illustrate the basic concepts:

A state channel is established by two parties through a transaction that locks the shared state on the blockchain. This transaction is called the ‘funding transaction’ or ‘anchor transaction’. This transaction must be settled in the blockchain (mined) in order to establish the channel. Once the funding transaction has been settled the two parties can start exchanging transactions called ‘commitment transactions’ . These transactions are held ‘off-chain’ until the channel is closed. When exchanging commitment transactions the two parties invalidate the previous state so the last state or the most up-to-date transaction state is the one it can be redeemed on the blockchain. Finally the channel can be closed cooperatively by submitting a final ‘settlement transaction’ to the blockchain or by either party submitting the last commitment transaction to the blockchain.

Only two transactions are settled on the blockchain, the ‘funding transaction’ and the ‘settlement transaction’. In between these two, there can be as many ‘commitment transactions’ as we want, they will alter the shared state, holding always the last state to be ready to settle on the blockchain whenever it’s needed.

A Payment Channel Practical Example

Let’s suppose Juan and Sarah establish a payment channel. Sarah wants to learn coding, and Juan teaches her by a hourly rate of 0.25 Bitcoin using a streaming software that uses payment channels automatically. Sarah funds the channel with 1 bitcoin (funding transaction). Sarah uses her UTXO’s and generates a multisignature output with Juan’s address. Once the transaction is sent to the blockchain and mined, the channel is ‘valid’ and then the teaching session starts. After one hour the software automatically generates a commitment transaction that changes the channel balance to credit 0.25 bitcoin to Juan’s address and refunds 0.75 bitcoin to Sarah. When two hours passed, another commitment transaction alter the shared state resulting in 0.5 btc in total to Juan’s address and 0.5 to Sarah’s address. After that, Sarah’s is tired of all the coding and decide to stop the session, either Juan or Sarah can transmit the final state transaction for settlement on the blockchain. This last transaction (settlement transaction) pays Juan for the two hours session of coding and refunds Sarah the remaining bitcoins of the funding transaction. This transaction is settled on the blockchain. Notice that the funding transaction was of only one bitcoin, so in this case that was the ‘channel capacity’ meaning that this channel only allowed Juan to teach a maximum of 4 hours.

Funding transaction of a state channel

Series of transactions on a state channel

Side Note: There’s a problem with this example. Because the channels need a funding transaction provided by one of the parties it can lead to trustless problems. Imagine Sarah had 3 hours lesson, so the balance will be 0.75 bitcoin to Juan and 0.25 bitcoin to Sarah, but why would she transmit to the blockchain the last balance as the settlement transaction? She could send the first transaction (0.25 to Juan, 0.75 to her) and pay only for one hour lesson when she had 3. This kind of problem can be solved with ‘time locks’ and ‘asymmetric revocable commitments’. We won’t see the details in this blog post, but it basically means that every transaction on the channel has a locked time in the future making it refundable if the timelock expired, and the transactions also include a key which one party can punish the other if they cheat.

Hash Time Lock Contracts (HTLC)

If we want to go deeper on the mechanisms of the payment channels, we have to understand what HTLC is. The HTLC is a special smart contract for using in payment channels that allows participants to commit funds to a redeemable secret with and expiration time. Let’s say Sarah want’s to pay Juan one bitcoin over an already open payment channel. First, Juan has to generate a secret “R” which only Juan will know about. Second, he will hash the “R” secret with a hash function, getting a “H” hash.

Hash(“R”) = “H”

Third, he can send the hash “H” to Sarah and she can make a transaction and put the “H” hash in the lock script with a flag that indicates the time limit to redeem the funds. Now, only the person who knows the secret “R” to fulfill the condition of the hash can redeem the bitcoin. The time limit is because if the secret “R” is not revealed, the payer of the HTLC can get a refund after a finite amount of time passed, or more precisely after certain amount of blocks.

The Lightning Network (LN)

The LN is one of the scaling approaches to the bitcoin blockchain. It’s a routed network of bidirectional payment channels connected end-to-end, meaning any participant can route a payment from channel to channel without using any of the intermediaries.

Let’s see an example with five participants; we have differents channels that connects Juan to Sarah, Sarah to Kim, Kim to Ryan and Ryan to Florence.

So, Juan wants to pay Florence one bitcoin, but he isn’t directly connected to Florence, and he doesn’t want to open an new direct channel to Florence as he has to commit more money to open a LN channel. Juan’s Lightning Node has the ability to connect to Sarah’s and discover new routes between payment channels, and it also has the ability to connect over the internet with Florence’s node. As we’ve seen before, Florence generates a secret “R” that only she knows. She hashes it and send the hash “H” to Juan’s node.

The LN channels connection example

Now, Juan’s node creates an HTLC payable to someone who knows the secret that can solve the hash “H”, with a 10-block refund timeout, for an amount of 1.003 Bitcoin. Why do we need the extra 003 Bitcoin you may be wondering? This extra money will be used to compensate the intermediate nodes for their participation in the routing of the payment.

Juan sends the HTLC to Sarah; the HTLC sent to Sarah means that Juan’s is commiting 1.003 of his channel balance to be paid to Sarah if she knows the secret, or refunded back if 10 blocks elapse. Sarah doesn’t knows the secret to claim the 1.003 locked by Juan, instead she creates another HTLC on her payment channel to Kim. On this HTLC Sarah commits 1.002 bitcoin to someone who knows the secret to solve the hash “H” for 9 blocks. In the same fashion, Kim commits an HTLC of 1.001 to hash “H” for 8 blocks to her channel with Ryan. From Sarah and Kim’s perspective, if the secret “R” is known, they will gain 0.001 each one on and if it isn’t known they lose nothing. Finally, Ryan offers an HTLC to Florence commiting 1 bitcoin for 7 blocks to hash “H”. At this point, Florence knows the secret “R” to solve the Hash “H”! She can therefore claim the HTLC from Ryan. She sends the “R” secret to Ryan and gets the 1 bitcoin. Now Ryan has the secret “R” so he can claim the HTLC committed by Kim on their channel and get the 0.001 bitcoin on their channel balance. Flowing back through the route the secret “R” allows each participant to claim the difference in the balance of their channels. That is the incentive of the participants to route payments, they put a “stake” on their personal channel balance (plus a fee), and if the secret is known, they can claim back their “stake” and earn the fee.

Juan has paid Florence 1 bitcoin without opening a direct channel to her. None of the intermediate parties in the payment route trust each other and for their help routing the payment they earn a small fee. Beautiful isn’t it? XD

This post was an attempt to introduce you to the payment channels and the Lightning Network. I believe it’s good to have a basic understanding of payment channels before you dig deeper into the LN. There is a lot of information online about the Lightning Network specifically, so I will finish this post here. I hope you learnt something new, you can follow me on twitter for Blockchain related news, topics and insights.

Call to Action

Here’s more links about the LN if you want to dig deeper: