HTLC or Hash Time Locked Contract are a type of smart contracts or smart contract that are used to create payments channels.
UOne of the most powerful technologies within the programming language of Bitcoin script are the known HTLC or Hash Time Locked Contract. These are a type of smart contracts or smart contract whose main capacity is to create payment channels or payments channels. In this way, HTLCs allow the construction of technology such as Lightning Network (LN) both in Bitcoin and in other cryptocurrencies compatible with this capacity. This means that HTLCs allow creating second layer protocols capable of greatly accelerating the scalability of Bitcoin. All this without giving up the security of this blockchain.
However, HTLCs are much more than just a smart contract. They are the union of several other technologies that in the end allow a much more complex functionality and according to the growth needs of Bitcoin.
In this Bit2Me Academy article you will learn more about the ins and outs and the potential of this blockchain algorithm.
Origin of HTLC
The origin of HTLCs goes back to the need to create mechanisms that allow greater scalability in Bitcoin. Curiously, the first ideas that led to the HTLC are quite original, curious and even problematic in some cases as you can see below:
Satoshi Nakamoto's nSequence Channel
The first idea that led to the HTLC came from the very Satoshi Nakamoto, with the so-called nSequence Channels. These types of payment channels are created using the Op_code nSequence and nLockTime. In this way, a system could be created in which the user could send a transaction with a value of nLockTime (a time lock) and an nSequence (a value that allows the replacement of the transaction by another). In this way, the user can make a certain amount of "instant" purchases and payments.
They would then be added to a final transaction that would replace the initial transaction before the initial nLockTime and nSequence were finally closed. In this way, the new transaction would pay all the expenses of the purchases made in the same operation.
This is possible because:
- The nSequences were designed to allow to replace transactions in the mempool, if this value was not marked with the hexadecimal value 0xFFFFFFFF, since if it was marked with that value the TX could not be replaced. In fact, this small design was what led to the creation of the Replace by Fee or RBF. The idea behind its use in the nSequence Channels was to add payment operations in a TX and replace it in the mempool, until finally said TX was considered as a final transaction (marking it with 0xFFFFFFFF in its nSequence).
- With nLockTime, a time limit would be set so that the miners could finally take the TX and confirm it. As a curious fact, nLockTime only works if nSequence is different from 0xFFFFFFFF, so effectively this value serves to guarantee that nSequence Channels are cheated, ensuring payment to the seller after a while, even if the channel has not been closed by nSequence.
Certainly this is a very basic solution, one-way (only the creator of the TX could handle it), with a limited time to live (the use of nLockTime and nSequence does not allow infinite operation) and without secure consensus rules (everything happens in the mempool where nothing is confirmed). But still, it was still a revealing idea.
And, seeing Bitcoin as a means to create payment channels and build systems powered by its OP_CODE opened up many possibilities, something that Nakamoto showed gracefully with this idea. The best? This idea was applicable since version 0.1.0 of Bitcoin, so it has been part of the protocol since its inception.
Spilman and CLTV channels
Two other well-known forms of payment channels are Spilman Channels and the CLTV Channels. The first of these was proposed by Jeremy Spilman, in which multi-signature transactions are combined with the use of nLockTime to avoid traps that allow the theft of funds. Basically, a Spilman Channel consists of:
- Create a 2-of-2 multi-signature transaction where the buyer and seller create the payment channel. The transaction is only created, but not transmitted to the network until the entire operation is done. This first transaction is known as a financing transaction.
- Next, a transaction is created that spends the previous one using nLockTime that guarantees the payment of the multi-signature TX. This transaction is delivered to the seller, who signs it and returns it to the buyer.
- The first TX is sent to the network for confirmation, and once confirmed you can start ordering whatever you want, since the payment channel has been opened.
- Now with each new payment transaction, a TX is created that spends the financing transaction (the first transaction created). This operation sends the payment of what you ask to the seller and returns the change to the buyer. The buyer can spend as much as he wants as long as his financing transaction allows it, if he exceeds the limit, he will not be able to continue spending. If you have finished spending, closing the channel with a change, this will go to the buyer automatically.
This system can also be created using the OP_CODE, OP_CHECKLOCKTIMEVERIFY(CLTV). In this case, the CLTV only allows you to include new conditions for closing the payment channel that avoid certain traps (such as the seller not wanting to close the payment channel when you want to stop consuming). In addition, the use of CLTV minimizes the steps by not needing to create the second transaction of the Spilman channel.
These two initial experiences were what led to the creation of the HTLCs, which later led to the creation of the Lightning Network. This in order to implement a second layer in the Bitcoin blockchain network to manage transactions outside of it through payment channels. This was made possible by the work of Joseph Poon and Tadge Dryja, who came up with this system in 2016.
How do HTLCs work?
The operation of the HTLC falls into two very important parts. The first is its ability to perform hashlocks, or blockages by hash of the transactions that are carried out. And the second is the ability to perform time lock, or time locks of those same transactions. These two functions together are those that allow HTLCs to execute transactions under certain conditions agreed upon in the execution of the contract. Best of all, these transactions are protected at the hash and time level. This makes them very secure compared to the initial payment channel models, such as the nSequence Channel.
The idea behind is that when a participant is interested in making a transaction, he can contact another person and reach an agreement. This agreement allows both of you to carry out transactions under conditions that you both accept. Thus, both parties can be sure that there will be no cheating in their operations. This provides the assurance that funds cannot be maliciously accessed ahead of time. And, at the same time, that the transactions carried out are completed correctly.
To do this, the HTLC creates a unique hash of the private key of the transaction that is delivered to each of the parties (what is possible by the hashlock). In this way, each party must participate in the transaction both to open and close the payment channel. Without both hashes, the transaction (once opened) cannot be closed to claim payment. This forces communication between the parties so that the end of the transaction is signed together.
A second additional protection is given by the timelock, with which a reasonable time is specified so that those who participate in the transaction can perform the necessary actions so that the transaction is carried out without inconvenience. If this time elapses and the transaction is not closed, the secondary conditions of said transaction are executed, which allow the funds to be recovered to their original owners. Of course, the conditions may be different, but the purpose of the timelock is to allow time for the parties to close the channel in a good way, without resorting to secondary instructions.
The HTLC contract model was designed with the launch of Bitcoin's Lightning Network in mind, a network of instant off-chain payments that benefits from them to offer security to its users.
Main uses of HTLC
The main use of HTLCs is in the creation of payment channels, as described by Poon and Dryja in their work on the Lightning Network. In fact, thanks to HTLCs, this type of system is safe and allows two-way communication, both between the channel's participants and creators, as well as the sidechain and the mainchain of the cryptocurrency where the HTLC is executed. In this sense, HTLCs are a reliable method to build these types of advanced payment functions, as LN has shown so far.
Another important use of HTLCs is in atomic swaps or atomic swaps. Thanks to their off-chain capability, HTLCs can intercommunicate two different blockchains and allow their users to perform instantaneous atomic swaps that can then go seamlessly to the mainchain.
Pros and cons of HTLC
One of the biggest advantages of HTLCs is facilitating transactions on P2P payment channels. In this way, it is easy to create a network of nodes that handle all these channels off-chain, and route these payments so that the parties receive the payments safely. In this way, without having to rely on intermediate nodes, it is possible to create a gigantic, almost instantaneous, secure and very low-cost payment network.
Another point in favor of HTLCs is that payment transactions can be protected with well-specified conditions. In this way, the theft of funds or the malicious action of the parties within the system can be avoided.
Additionally, HTLCs provide the Bitcoin network with a great improvement in its scalability and ability to make micropayments. This while reducing on-chain bottlenecks, commissions are reduced and the network scales to serve more and more people.
However, not everything is positive. Many experts from the world of cryptography have found some problems in HTLCs. First of all there is the point of traceability of operations, which means that payments made with HTLC are not anonymous. Another drawback is that HTLCs can result in more complex systems and therefore software with undetected security problems.
How much do you know, cryptonuta?
Are HTLCs a real way to improve payment systems using Bitcoin?TRUE!
Payment channels since the time of Satoshi Nakamoto, have been seen as the way forward to improve the payment experience using Bitcoin. This has led developers and much of the Bitcoin community to see payment channels (including HTLCs) as the future of instant payments, starting with the leading technology in this regard, Lightning Network (LN).
Other alternatives to HTLC
Despite the advantages offered by the implementation of HTLCs, some developers have their interest focused on the development of new alternatives to these smart contracts. Developers of the Lightning Network ecosystem are joining forces to make profound changes to this network. This with a view to using PTLC in the execution of transactions with a much higher level of privacy than those currently offered by HTLC.
Other smart contracts that are emerging in the execution of multi-signature transactions such as Taproot. Everything seeks to reach a new era of smart contracts in the Bitcoin network that give greater privacy, versatility and security to transactions.