If you’ve been keeping up with the Blockchain news cycle, you know that the scalability issue is still very much pressing for the Bitcoin network.
Currently, the blocks on Bitcoin are being mined every 10 minutes and the block size is limited to 1 megabyte. The network is capable of processing nearly 2000 transactions every 10 minutes which means it can only handle about 3 transactions per second. Compare this capacity to the throughput of Visa (~1700TPS) or Paypal (193TPS) and you’ll see that, at this point, Bitcoin is a pathetically slow payment system.
Bitcoin is a pathetically slow payment system.
Click To Tweet
To remedy this problem, a number of initiatives were proposed both by Bitcoin core developers and the community over the years. The most promising of them include Segregated Witness, Schnorr signatures and, of course, payment channels which are the topic of today’s article.
In this post, we will discuss how payment channels work and talk about the outcomes their adoption might lead to. Strap in!
What are payment channels?
Before it is put into a block or even visible to the network, each Bitcoin transaction is preliminary signed off-chain.
If John wants to give some bitcoins to Jane he builds up a transaction to send outputs from his wallet. He signs it with his private key, and, then, broadcasts it out to the Bitcoin blockchain. And it’s only afterward that the miners learn of its existence, pick the transaction up and, eventually, write it into the distributed ledger (the procedure which is both time-consuming and costly).
Using a payment channel, however, John can run that same transaction “privately”, never showing to the Bitcoin network. He can settle the payment peer-to-peer – instantly and at no cost.
How do payment channels work?
There wouldn’t be such a thing as a payment channel, on Bitcoin or otherwise if it wasn’t for the advent of multisig transactions which are effectively a form of smart contracts.
The lightning network (and other payment channel specifications) use two-of-two multisig addresses which, as the name suggests, require two private keys to authorize unlocking funds from them.
Here’s how it works: suppose John and Jane have to transact regularly and instead of doing it in a conventional way, which would incur substantial fees, they create a multisig address to which they both agree to send a certain number of bitcoins. For the sake of clarity, let’s say each contributes 4 bitcoins making the channel worth 8 bitcoins in total.
Note : normally this wouldn’t be the case as payment channels are much more suitable for micro-payments.
Aside from that, they both create a secret value and exchange hashes of it between one another.
John then builds a subsequent transaction to the opening one; in the Lightning Network, it is called a commitment transaction. As he attempts to give Jane one bitcoin, he sends 3 bitcoins to himself and 5 remaining ones to a multisig address that has a CSV-lock in it. If Jane tries to get to the funds out of it, she’ll have to wait a certain period of time (for example until 100 of new blocks are mined and written into a blockchain) before the coins are unlocked.
Meanwhile, John could drain the address as well, but he needs a secret value of which Jane has given him the hash to do so.
After signing the transaction John hands it to Jane directly (instead of broadcasting it to Bitcoin).
Next, Jane mirrors exactly what John have done. She, too, creates a subsequent commitment transaction but sends 5 bitcoins to herself and 3 to the multisig address. The restrictions are valid for her as well – she knows Bob can’t get the funds until after 100 new blocks are mined and that she can’t unlock them without applying John’s secret (to which she has a hash). So Jane sends the signed, half-valid transaction to John and, finally, they broadcast the opening transaction (and pay a fee to miners) to get started with a payment channel.
Both of the commitment transactions remain half-valid; neither John or Jane signs and broadcasts them as that would shut down their payment channel.
At this point, we’re through with the first “payment”.
Now, if John wants to send another bitcoin to Jane (or Jane wants to send one back), they create another pair of subsequent transactions – this time without the opening one. They redistribute, so to speak, the balance on the channel and update its state. They create new secret values and hashes and, at the same time, exchange the older secrets – from the first transaction – between one another.
This is done to ensure trust.
If Jane decides to close the channel on her own (by broadcasting the first commitment transaction to the network) John would get his 3 bitcoins right away. Jane, on the other hand, will have to wait until 100 new blocks are mined before she can get the funds due to the CSV-lock. But, as we’ve mentioned earlier, there are two ways of unlocking funds from the multisig address – John can beat Jane to it by using the secret (from the first transaction) she has just given him. So, if she decides to cheat, John gets all the money.
Same works the other way around. John knows Jane can use his secret to drain the address; he’s incentivized strongly to keep on good behavior.
Once the payment channel is opened and recorded into the immutable blockchain, John and Jane can keep transacting across it indefinitely, incurring no fees. The only other time they’ll have pay again is when they decide to close the channel.
If you’d like to learn more about payment channels and blockchain tech in general – reach out to our expert. He’ll gladly provide you with a free consultation.
The post Bidirectional Payment Channels: The Future of Blockchain Transactions appeared first on Software Company Perfectial.
Top comments (0)