How to run add-on bitcoin blockchain
Lightning Network (LN) is probably one of the most anticipated innovations for Bitcoin blockchain. The idea first proposed by Joseph Poon (Joseph Poon) and Taj Dria (Tadge Dryja) about two years ago. Lightning Network promises support for an unlimited number of transactions between users performed in a network of payment channels deployed on top of the blockchain. At the same time, the system inherits the reliability of Bitcoin blockchain.
Several companies are working on the implementation of the LN protocol, including Lightning Labs, Blockstream, ACINQ, and Bitfury. This technology will allow to make micropayments using bitcoins, which will significantly expand the possibilities and scope of cryptocurrency. In this article we will talk about what the Lightning Network concept is built on and how this network works.
/ image Iraia MartĂnez CC
')
Lightning Network is a network of two-way payment channels through which you can perform an unlimited number of transactions, without recording each transaction in the blockchain. The network is built according to the principles of mesh networks, that is, it is decentralized and distributed.
This allows you to eliminate the threat of transaction censorship and violation of users' privacy, monopolization of the transaction processing market, and also to avoid having a single point of failure. The security of the system is ensured with the help of contracts with hashing and temporary blocking, which are implemented using built-in bitcoin scripts.
The concept of payment channels was introduced even before the Lightning Network. Classic payment channels are useful for performing a certain range of tasks, but they have a limitation - they are unidirectional. In this case, one user can send Bitcoins to another, but to perform the reverse operation, you will have to create a new channel. Therefore, Poon and Dria proposed to introduce trustworthy bidirectional payment channels.
Lightning high-level network layout
As a result, two users are able to conduct transactions among themselves within the payment channel without any restrictions. The funds transferred in this way become “real” at the moment when the last (closing) transaction is sent and recorded in the Bitcoin blockchain. Consider in more detail how this works.
To set up a bidirectional payment channel, two participants define a funding transaction — that is, they deposit a certain amount of funds to one 2-of-2 multisig address. Bitcoins at this address can be spent (sent to other bitcoin addresses) only if the transaction is signed by both channel creators (we will call them Alice and Bob) with their private keys. Each member of the payment channel has exactly one private key. In addition, participants generate secrets — random sequences of bits — and exchange their hashes.
After that, Alice forms a so-called commitment transaction based on the opening transaction. This transaction, being published on the blockchain, sends the number of bitcoins available on the channel to the address controlled by Alice, and the balance to another multisig address. This second address can be unblocked by Bob, but only after 1 thousand blocks arrive in the blockchain. In general, a delay of 1 thousand blocks is a parameter that is configured when a channel is opened.
Also, bitcoins at this address can be unlocked by Alice, but only if she attaches a secret, the hash of which Bob sent to her at the time of the channel establishment (she does not know the secret, therefore she cannot unblock bitcoins immediately). Then Alice signs a transaction commitment, but sends it not to the blockchain, but directly to Bob. This transaction will allow Bob to close the channel at any time by publishing it to the blockchain, which will cause Alice to receive her money instantly, and Bob will be able to pick up her bitcoins with a delay of 1,000 blocks. In turn, Bob creates the same but symmetrical transaction, then signs it and sends it to Alice.
After exchanging semi-correct transactions, Alice and Bob sign and send the funding transaction to the blockchain. It is believed that after that the bidirectional channel is open. Now both Alice and Bob can send money to each other within the payment channel directly and an unlimited number of times. At the same time, Alice and Bob must draw up new transaction-commitments with an updated distribution of funds in the channel and with new secrets (which they again sign and send to each other).
However, now both participants reveal their secrets from the previous operation. This makes it impossible for them to send a previous transaction to the blockchain in order to get bitcoins already sent: for example, if Alice tries to send an old obligation from Bob to the network, Bob will be able to pick up all bitcoins from the established channel. This means that Alice and Bob are economically interested in following the rules and broadcasting only actual transactions to the network.
If Alice and Bob want to close the channel by mutual agreement, they can simply create a transaction that overrides everything that happened after the opening transaction. After its signing and sending the channel is considered closed. Thus, only opening and closing transactions will be transferred to the bitcoin network, even if between Alice and Bob made millions of payments to each other. It is this feature that allows you to significantly unload the blockchain.
If one of the participants in a bilateral channel wants to transfer bitcoins to a third party, he can use his “partner” as a guarantor of the transaction (if the latter already has a payment channel with a third party). Suppose Alice wants to send one bitcoin to a third party, say Carlos. She can send this bitcoin to Bob, after which Bob will send him to Carlos as an intermediary.
The integrity and security of such a transaction is achieved through the use of cryptography techniques. Alice asks Carlos to generate a secret and send her his hash to her, and exchange the secret for a bitcoin from the Bob channel. After that, she returns Bitcoin to Bob when he provides the secret obtained from Carlos (Alice’s hash is known and she can easily verify the accuracy of the secret). At the same time, Bob can withhold a small and pre-negotiated part of bitcoins as a commission for making a payment.
In this scenario, the broker (Bob) should not trust Carlos and Alice. To ensure its security, so-called hash and temporary blocking contracts (HTLC) are used. When creating an HTLC channel Alice-Bob, bitcoins are sent to a new address with a multi-signature, which can be unblocked in two ways: either Bob specifies the address and secret, or Alice specifies only the signature - however, in the latter case, the CLTV lock will work: network only after a certain (long) time. During this time, Bob must have time to create a transaction with a signature and a value in order to get the funds locked. Thus, as soon as Bob gives the money to Carlos, he learns the secret, which means that he is guaranteed to be able to withdraw his money from the channel with Alice. This idea is generalized to more than one intermediary.
The Lightning Network technology is considered to be one of the best solutions for increasing the bandwidth of the Bitcoin network, offering, as already noted, a way to perform most transactions outside the blockchain. One of the defining features of LN is the ability to send payments to any member of the network through a chain of payment channels between users. Due to this, network members may not create new payment channels every time they need to conduct a transaction with a network member with which there is no payment channel. However, the construction of the route of payment channels from the recipient to the sender is quite a difficult task - it is necessary to select the optimal path (according to different criteria, for example, by time or cost), which would allow Bitcoins to “pass” from the sender to the recipient.
The bitcoin community offered several routing algorithms for LN. One of the first decisions was the proposal to divide the nodes into two classes: wallets and routing nodes (hubs), which are remunerated for their services. The first could only make payments, and the second - redirect them. This scheme proved to be quite effective, since the knowledge of all the hubs allows you to accurately build a route to any node. At the same time, such an approach was detrimental to the concept of decentralization, one of the principles of the Bitcoin network.
Therefore, another idea was proposed. Several nodes daily and randomly received the status of "beacons". All nodes tried to make routes to these lighthouses and use the built “tracks” to send payments. This scheme turned out to be more decentralized than the previous one, however, open for conducting Sibylla attacks (since being in the status of a beacon is beneficial for the node). Moreover, most of the built routes became useless after changing the cluster of lighthouses.
Therefore, Bitfury proposed a new (hybrid) version of the routing algorithm, called Flare. The algorithm consists of two stages. The first is a proactive update of the subset scheme of existing channels, which stores information about the general network topology. The second stage is the reactive construction of the route based on the request for finding the path to a specific recipient, as well as collecting dynamic information about the LN network - the size of the commissions, the reliability of the nodes, the delay time, etc.
Flare routing algorithm
The information gathered at the proactive stage includes the channels of the closest nodes (environment) and the paths to randomly selected nodes (personal beacons) at a remote distance. The existence of payment channels is verified using bitcoin blockchain information and data provided by channel members.
Each node updates its network information by regularly filling out the routing table. When a node decides to send bitcoins using LN, it looks at its own routing table and the nearest neighbor table that is closest to the destination in the address space to find the likely routes in the network. The table defines the subsystem of open channels and helps to find the recipient of funds (or, if it was not possible to find it, identifies those beacons that can "help" with this).
As a result, the node has at its disposal a map of the local environment within the network with random "areas of visibility" formed by beacon nodes. The combination of local nodes and beacon nodes allows customers to minimize the cost of routing and increase the likelihood of finding a route.
Using this specification, the ACINQ research team was able to implement and test the algorithm on 2.5 thousand AWS nodes. True, the part that was tested was only the first of the two stages of Lightning routing. However, according to the test results, it was found that the Flare algorithm is able to determine the payment path in 5 seconds with a probability of 80%. And this is a very good step towards the commercial implementation of the Lightning network.
Several companies are working on the implementation of the LN protocol, including Lightning Labs, Blockstream, ACINQ, and Bitfury. This technology will allow to make micropayments using bitcoins, which will significantly expand the possibilities and scope of cryptocurrency. In this article we will talk about what the Lightning Network concept is built on and how this network works.
/ image Iraia MartĂnez CC')
Lightning Network is a network of two-way payment channels through which you can perform an unlimited number of transactions, without recording each transaction in the blockchain. The network is built according to the principles of mesh networks, that is, it is decentralized and distributed.
This allows you to eliminate the threat of transaction censorship and violation of users' privacy, monopolization of the transaction processing market, and also to avoid having a single point of failure. The security of the system is ensured with the help of contracts with hashing and temporary blocking, which are implemented using built-in bitcoin scripts.
The concept of payment channels was introduced even before the Lightning Network. Classic payment channels are useful for performing a certain range of tasks, but they have a limitation - they are unidirectional. In this case, one user can send Bitcoins to another, but to perform the reverse operation, you will have to create a new channel. Therefore, Poon and Dria proposed to introduce trustworthy bidirectional payment channels.
Lightning high-level network layout
As a result, two users are able to conduct transactions among themselves within the payment channel without any restrictions. The funds transferred in this way become “real” at the moment when the last (closing) transaction is sent and recorded in the Bitcoin blockchain. Consider in more detail how this works.
Establishing Bidirectional Channel
To set up a bidirectional payment channel, two participants define a funding transaction — that is, they deposit a certain amount of funds to one 2-of-2 multisig address. Bitcoins at this address can be spent (sent to other bitcoin addresses) only if the transaction is signed by both channel creators (we will call them Alice and Bob) with their private keys. Each member of the payment channel has exactly one private key. In addition, participants generate secrets — random sequences of bits — and exchange their hashes.
After that, Alice forms a so-called commitment transaction based on the opening transaction. This transaction, being published on the blockchain, sends the number of bitcoins available on the channel to the address controlled by Alice, and the balance to another multisig address. This second address can be unblocked by Bob, but only after 1 thousand blocks arrive in the blockchain. In general, a delay of 1 thousand blocks is a parameter that is configured when a channel is opened.
Also, bitcoins at this address can be unlocked by Alice, but only if she attaches a secret, the hash of which Bob sent to her at the time of the channel establishment (she does not know the secret, therefore she cannot unblock bitcoins immediately). Then Alice signs a transaction commitment, but sends it not to the blockchain, but directly to Bob. This transaction will allow Bob to close the channel at any time by publishing it to the blockchain, which will cause Alice to receive her money instantly, and Bob will be able to pick up her bitcoins with a delay of 1,000 blocks. In turn, Bob creates the same but symmetrical transaction, then signs it and sends it to Alice.
After exchanging semi-correct transactions, Alice and Bob sign and send the funding transaction to the blockchain. It is believed that after that the bidirectional channel is open. Now both Alice and Bob can send money to each other within the payment channel directly and an unlimited number of times. At the same time, Alice and Bob must draw up new transaction-commitments with an updated distribution of funds in the channel and with new secrets (which they again sign and send to each other).
However, now both participants reveal their secrets from the previous operation. This makes it impossible for them to send a previous transaction to the blockchain in order to get bitcoins already sent: for example, if Alice tries to send an old obligation from Bob to the network, Bob will be able to pick up all bitcoins from the established channel. This means that Alice and Bob are economically interested in following the rules and broadcasting only actual transactions to the network.
If Alice and Bob want to close the channel by mutual agreement, they can simply create a transaction that overrides everything that happened after the opening transaction. After its signing and sending the channel is considered closed. Thus, only opening and closing transactions will be transferred to the bitcoin network, even if between Alice and Bob made millions of payments to each other. It is this feature that allows you to significantly unload the blockchain.
Networking and tripartite sharing
If one of the participants in a bilateral channel wants to transfer bitcoins to a third party, he can use his “partner” as a guarantor of the transaction (if the latter already has a payment channel with a third party). Suppose Alice wants to send one bitcoin to a third party, say Carlos. She can send this bitcoin to Bob, after which Bob will send him to Carlos as an intermediary.
The integrity and security of such a transaction is achieved through the use of cryptography techniques. Alice asks Carlos to generate a secret and send her his hash to her, and exchange the secret for a bitcoin from the Bob channel. After that, she returns Bitcoin to Bob when he provides the secret obtained from Carlos (Alice’s hash is known and she can easily verify the accuracy of the secret). At the same time, Bob can withhold a small and pre-negotiated part of bitcoins as a commission for making a payment.
In this scenario, the broker (Bob) should not trust Carlos and Alice. To ensure its security, so-called hash and temporary blocking contracts (HTLC) are used. When creating an HTLC channel Alice-Bob, bitcoins are sent to a new address with a multi-signature, which can be unblocked in two ways: either Bob specifies the address and secret, or Alice specifies only the signature - however, in the latter case, the CLTV lock will work: network only after a certain (long) time. During this time, Bob must have time to create a transaction with a signature and a value in order to get the funds locked. Thus, as soon as Bob gives the money to Carlos, he learns the secret, which means that he is guaranteed to be able to withdraw his money from the channel with Alice. This idea is generalized to more than one intermediary.
Lightning Network Routing
The Lightning Network technology is considered to be one of the best solutions for increasing the bandwidth of the Bitcoin network, offering, as already noted, a way to perform most transactions outside the blockchain. One of the defining features of LN is the ability to send payments to any member of the network through a chain of payment channels between users. Due to this, network members may not create new payment channels every time they need to conduct a transaction with a network member with which there is no payment channel. However, the construction of the route of payment channels from the recipient to the sender is quite a difficult task - it is necessary to select the optimal path (according to different criteria, for example, by time or cost), which would allow Bitcoins to “pass” from the sender to the recipient.
The bitcoin community offered several routing algorithms for LN. One of the first decisions was the proposal to divide the nodes into two classes: wallets and routing nodes (hubs), which are remunerated for their services. The first could only make payments, and the second - redirect them. This scheme proved to be quite effective, since the knowledge of all the hubs allows you to accurately build a route to any node. At the same time, such an approach was detrimental to the concept of decentralization, one of the principles of the Bitcoin network.
Therefore, another idea was proposed. Several nodes daily and randomly received the status of "beacons". All nodes tried to make routes to these lighthouses and use the built “tracks” to send payments. This scheme turned out to be more decentralized than the previous one, however, open for conducting Sibylla attacks (since being in the status of a beacon is beneficial for the node). Moreover, most of the built routes became useless after changing the cluster of lighthouses.
Therefore, Bitfury proposed a new (hybrid) version of the routing algorithm, called Flare. The algorithm consists of two stages. The first is a proactive update of the subset scheme of existing channels, which stores information about the general network topology. The second stage is the reactive construction of the route based on the request for finding the path to a specific recipient, as well as collecting dynamic information about the LN network - the size of the commissions, the reliability of the nodes, the delay time, etc.
Flare routing algorithm
The information gathered at the proactive stage includes the channels of the closest nodes (environment) and the paths to randomly selected nodes (personal beacons) at a remote distance. The existence of payment channels is verified using bitcoin blockchain information and data provided by channel members.
Each node updates its network information by regularly filling out the routing table. When a node decides to send bitcoins using LN, it looks at its own routing table and the nearest neighbor table that is closest to the destination in the address space to find the likely routes in the network. The table defines the subsystem of open channels and helps to find the recipient of funds (or, if it was not possible to find it, identifies those beacons that can "help" with this).
As a result, the node has at its disposal a map of the local environment within the network with random "areas of visibility" formed by beacon nodes. The combination of local nodes and beacon nodes allows customers to minimize the cost of routing and increase the likelihood of finding a route.
Using this specification, the ACINQ research team was able to implement and test the algorithm on 2.5 thousand AWS nodes. True, the part that was tested was only the first of the two stages of Lightning routing. However, according to the test results, it was found that the Flare algorithm is able to determine the payment path in 5 seconds with a probability of 80%. And this is a very good step towards the commercial implementation of the Lightning network.
Source: https://habr.com/ru/post/331268/
All Articles