BchainTalk Forum - Community for Blockchain Believers

Join like-minded people in a collaborative culture to share & learn.

BchainTalk Forum - Community for Blockchain Believers

Join like-minded people in a collaborative culture to share & learn.

Latest topics
» Bidooh — The World’s First Blockchain-based Facial Recognition Billboard
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu Nov 29, 2018 4:02 pm by Vladdirescu

» Smart Valor — The Future of Global Investments
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyTue Nov 13, 2018 6:06 pm by Vladdirescu

» Jur — Resolving Legal Disputes with the Help of Smart Contracts
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyTue Oct 30, 2018 7:08 pm by Vladdirescu

» CDRX — Blockchain Technology in the Traditional Securities Market
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu Oct 18, 2018 3:48 pm by Vladdirescu

» NoahCoin as a Key to Borderless Facilities of Noah Project
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu Oct 11, 2018 4:39 pm by Vladdirescu

» Iconiq Lab —  New ICO Accelerator and Decentralized Investment Fund
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyWed Oct 03, 2018 8:34 pm by Vladdirescu

» Raincheck — Global Bonus System and Loyalty Program on the Stellar Blockchain
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu Sep 13, 2018 6:09 pm by Vladdirescu

» Clintex (Clinical Trials Intelligence) — Alternative Treatment of the Future
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyMon Aug 27, 2018 12:47 am by Vladdirescu

» Mobu ICO— The Future of Security Tokenization
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu Aug 16, 2018 1:26 am by Vladdirescu

» Codex Protocol — Blockchain-based Title Registry of Art and Collectibles
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyWed Jul 11, 2018 6:32 pm by Vladdirescu

» INGOT Coin Develops An All-Inclusive Ecosystem to Bridge Markets, Revives Lost Demand
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyTue Jul 10, 2018 6:50 pm by Vladdirescu

» Japan Has Announced New Five-Point Regulations for Cryptocurrency Exchanges
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyTue Jul 10, 2018 3:16 am by Vladdirescu

» Trivver — Blockchain-Based Extended Reality Ad Exchange
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptySat Jun 30, 2018 5:38 pm by Vladdirescu

» OEL Foundation — Unified Logistics Blockchain Infrastructure
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyMon Jun 25, 2018 10:20 pm by Vladdirescu

» Quadrant Protocol — Data Ecosystem With Authenticity And Provenance
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptySat Jun 09, 2018 6:59 pm by Vladdirescu

» Pumapay Brings Crypto Payments into Daily Life, Raises $117 mln in Private Token Sale
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyMon Jun 04, 2018 6:47 pm by Vladdirescu

» FlipNpik — Social Media for Local and Small Businesses based on XLM
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu May 24, 2018 3:34 pm by Vladdirescu

» Japanese Bank MUFG Is Planning to Issue a Trial of Its Own Digital Currency
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu May 17, 2018 11:40 pm by Vladdirescu

» Blockchain Enters Poland’s Financial Market, Namely the Credit Office
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu May 17, 2018 10:55 pm by Vladdirescu

» HSBC Claims it Performed the World’s First Trade Transaction via Blockchain
Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel EmptyThu May 17, 2018 10:26 pm by Vladdirescu


Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel

View previous topic View next topic Go down

Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel Empty Understanding the Lightning Network, Part 1: Building a Bidirectional Bitcoin Payment Channel

Post by Artyom Mon Apr 24, 2017 1:55 pm

The Lightning Network is probably the most highly anticipated technological innovation to be deployed on top of Bitcoin. The payment layer, first proposed by Joseph Poon and Tadge Dryja about a year ago, promises to support a virtually unlimited number of off-chain transactions among users, at nearly no cost – while leveraging the security offered by Bitcoin.

At least three companies – Poon and Dryja's Lightning, Blockstream and Blockchain – are currently working on implementations of the technology. But few outside this small technological frontline fully grasp how the “future of micropayments” is set to boost Bitcoin’s capabilities.

In this three-part series, Bitcoin Magazine lays out the basic building blocks of the Lightning Network, and shows how they fit together to realize this upcoming protocol layer.

This first part of the series establishes the necessary building blocks, and shows how these can be combined to create “smart contracts,” which can be applied to realize the first requirement of the Lightning Network: a bidirectional payment channel.

(Note: Anyone with a solid understanding of Bitcoin can skip the building blocks.)

Building Block #1: Unconfirmed Transactions

At its heart, the Bitcoin protocol consists of transactions, that are typically linked to previous transactions, and potentially to future transactions. Each transaction contains inputs, which refer to addresses bitcoins are sent from, and outputs, which refer to addresses bitcoins are sent to. Additionally, inputs must include the requirements to send the bitcoins, like signatures that prove “ownership” of the input-addresses. Outputs, meanwhile, establish the new requirements, that must be included in the input of a subsequent transaction.

As one of its key features, the Lightning Network is built up from more or less regular Bitcoin transactions. It's just that these transactions are typically not actually broadcast over the Bitcoin network. Instead, they are stored locally, on the nodes of users - but they can be broadcast over the network at any time.

Unconfirmed Transaction
Building Block #2: Double-Spend Protection

The second building block for the Lightning Network probably doesn't require much explaining, as it's arguably the raison d'être for Bitcoin itself: double-spend protection. If two transactions (or: inputs) rely on the same output, only one can confirm.

The important thing to keep in mind here is that even unconfirmed transactions can be conflicting, meaning only one can ever confirm.

Double Spend
Building Block #3: Multisig

The third building block of the Lightning Network is also a straightforward one: multisignature (multisig) addresses. (Or more generally: P2SH-addresses.)

Multisig addresses are Bitcoin addresses that – as the name suggests - require multiple private keys to “unlock” and spend bitcoins from. Multisig addresses can be set up under all sorts of conditions. For instance to require two out of three possible keys, or fifteen out of fifteen, or just about any other combination.

The Lightning Network often uses two out of two (2-of-2) multisig set-ups. Unlocking bitcoins from 2-of-2 multisig addresses requires two signatures, from two dedicated keys.

Multisig
Building Block #4: Time-Locks

The fourth building block is the time-lock. Time-locks can “lock bitcoins up” in an output, to make them spendable (to be included in a subsequent input) only at some point in the future.

There are two different types of time-locks: the absolute type, called CheckLockTimeVerify (CLTV), and the relative type, CheckSequenceVerify (CSV). CLTV locks bitcoins up until a (more or less) concrete time in the future: an actual time and date, or a specific block height. CSV, instead, uses relative time. Once a CVS-output is recorded on the blockchain, it takes a specific amount of blocks from that point on before the bitcoins can be spent again.

Timelock
Building Block #5: Hash Values and Secrets

The fifth and final building block – cryptography - is the most fundamental building block of Bitcoin itself. But in the Lightning Network, it’s applied in a new way.

In short, a “value” or “secret” is a long and unique string of numbers that is practically impossible to guess, even for a computer with infinite tries. With a special calculation, this value (or secret) can be “hashed” into a different string of numbers, a “hash.” And here's the trick: anyone who knows the value can easily reproduce the hash. But this doesn't work the other way around; it's a one way street.

This trick can be utilized in Bitcoin itself, again to “lock bitcoins up.” (In fact, it's really how Bitcoin works.) For example, a hash can be included in an output, and require the subsequent input to include the corresponding value in order to be spendable.

Secret
The First Challenge: Bidirectional Payment Channels

Even before the Lightning Network was presented, the concept of payment channels had been around for some time. Typical payment channels are useful for certain purposes, but also limited: they are one-directional. Alice can pay Bob several off-chain transactions, but Bob cannot pay Alice through the same channel at all.

As a key feature of the Lightning Network, Poon and Dryja proposed trustless bidirectional payment channels.

Opening the Channel

To set up a bidirectional payment channel, both parties involved must first agree on an opening transaction. This opening transaction determines how many bitcoins each deposits into the channel.

Let's say Alice wants to send one bitcoin to Bob. Since Alice and Bob expect to transact more frequently, they decide to open up a bidirectional payment channel, and use this to send the bitcoin. (Sending a whole bitcoin is probably a lot for a payment channel, as these might be more useful for micropayments – but it's perfectly possible.)

To open the channel, Alice and Bob each send five bitcoins to a 2-of-2 multisig address. This is the “opening transaction.” Bitcoins can only be spent from this address if both Alice and Bob sign a subsequent transaction.

Additionally, Alice and Bob both create a secret (a string of numbers), and exchange the hash.

Alice now immediately creates a subsequent transaction from the opening transaction. This is a “commitment transaction.” With the commitment transaction, Alice sends four bitcoins to herself, and six bitcoins to a second multisig address. This second multisig address is a bit funky. It can be unlocked by Bob on his own, but only after 1000 extra blocks have been mined after it’s included on the blockchain; it includes a CSV-lock. Or, it can be opened by Alice on her own, but only if she also includes the secret for which Bob has just now given her the hash. (Of course, Alice has no idea what this secret is – she only knows hash – so there's no way she can make use of this option right now.)

Alice signs her end of this commitment transaction. But she doesn't broadcast it! Instead, she gives it to Bob.

Meanwhile, Bob does the same, but mirrored. He creates a commitment transaction as well, from which he sends six bitcoins to himself, and four to a funky new multisig-address. Alice can unlock this address if she waits an additional 1000 blocks, or Bob can unlock it with Alice using her secret.

Bob signs this half, and gives it to Alice.

After all this exchanging of “half-valid” commitment transactions and hashes of secrets, they both sign and broadcast the opening transaction, to make sure it's recorded on the blockchain. The channel is now officially open.

At this point, both Alice and Bob could sign and broadcast the half-valid commitment transaction they got from the other. If Alice does, Bob gets six bitcoins immediately. If Bob does, Alice gets four bitcoins immediately. But whomever signs and broadcasts the transaction will have to wait 1000 blocks to unlock the subsequent multisig-address, and claim the remaining bitcoins.

Payment Channel A
However, and this is the key trick of a payment channel: neither sign and broadcast their half of the transaction at all.

Updating the Channel

A little later, Bob wants to send Alice one bitcoin back. They want to update the channel state, to make the balance five-five again. To accomplish this, Alice and Bob do two things.

First, both repeat the process as described above (except that the opening transaction is already recorded on the blockchain; that part is skipped). This time, both Alice and Bob attribute themselves five bitcoins, and both attribute five bitcoins to funky multisig-addresses. The conditions for these multisig-addresses are similar, except that they require new secrets: both Alice and Bob provide each other withnew hashes. They both sign their new half valid commitment transaction, and give it to each other.

Second, Alice and Bob hand each other their first secrets, as used in the first set-up.

At this point, again, both Alice and Bob could sign and broadcast the new “half valid” commitment transaction they just got. Their counterparty would get five bitcoins immediately, while the broadcaster would have to wait 1000 blocks. As such, the channel is updated.

But what's stopping Bob from broadcasting the older commitment transaction instead? That commitment transaction led to a path that paid him six bitcoins, instead of five….

What’s stopping Bob, of course, is his first secret, which he has now given to Alice.

Bob cannot safely sign and broadcast the older commitment transaction any more, because Alice now knows Bob's first secret. If Bob were to sign and broadcast that commitment transaction, he would immediately send four bitcoins to Alice... and he would have to wait 1000 blocks to claim his own six bitcoins. That's a problem, because now that Alice knows his secret, she could use this time to beat Bob to the punch, and claim the other six bitcoins as well!

And since Bob has Alice’s secret too, this is just as true for the other way around. If Alice tries to sign and broadcast an old commitment transaction, Bob can steal all the bitcoins in the channel.

This of course means that both Alice and Bob are strongly incentivized to play fair, and only ever sign and broadcast the most recent state of the channel.

Payment Channel B
Next, this bidirectional payment channel set-up needs to expand to allow payments over a network. This is covered in the second article of this series.

Source:https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/

Artyom

Posts : 8
Reputation : 1
Join date : 2017-04-15

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum