Table of contents
No headings in the article.
This article is the first in a two-part series which aims to explain some of the technicalities of Lightning Network PTLCs and how they compare with HTLCs.
Overview of PTLCs
The Lightning Network protocol uses multihop locks for processing payments. According to the official docs on Multihop locks-scriptless payments, "Multihop locks are protocols that allow two parties to exchange coins and proof of payment without requiring a mutual funding multisig output. Instead, they are connected by hopping through intermediate nodes who are connected by having a shared funding multisig output." Currently, the lock system used in the Lightning Network is Hash Time-Locked Contracts (HTLCs). Point Time-Locked Contracts (PTLCs) have been proposed and are being used by a few companies like Suredbits, but they are still in experimental stages, with HTLCs being the predominant method of payment.
HTLCs have been the default method of payment in the Lightning Network v1.0. HTLCs are conditional payment contracts that say Alice will give Bob the stated bitcoin if Bob provides the pre-image to a specific hash. Otherwise, Alice can claim her bitcoin back when a certain amount of time has passed and she has not received the preimage – the HTLC has expired. A common "payment hash" can then be used to bind these contracts together over multiple hops in a payment path atomically. Because all payments along a given path can be connected by their hash, this can be a privacy issue. In this article by Suredbit, this issue is further highlighted: "This not only gives them information about routes that we don’t want them to have access to, but it also allows them to perform a “wormhole attack,” which consists of them working together to steal the fees of all intermediate hops between them."
Payment decorrelation, or the inability to correlate payments along a given route, was offered as a benefit of PTLCs. PTLCs therefore represent a privacy enhancement to HTLCs. It encrypts payments with a public key and decrypts them with a signature from a satisfied adaptor.
Signature adaptors (also known as adaptor signatures) are auxiliary signature data that commit to a hidden value. A locking mechanism is frequently used in Bitcoin contracts to assure the atomicity of a series of payments—all payments at each hop in the route will either succeed or fail. In the HTLC model, all payments in the route will typically be locked by committing to the same hash digest preimage; everyone eventually learns the preimage and can unlock their own payments off-chain, or can otherwise access their funds by using the HTLC-timeout or HTLC-success transactions. However, the issue with HTLC is that, if you have to go on-chain because an HTLC timed out (or you force-close), then, in some cases, you have to publish the preimage on-chain, at which point, everyone in the whole world can see your preimage, thereby leaking privacy.
Signature adaptors, on the other hand, do not require on-chain broadcast. A signature formed with an adaptor appears to anyone without the appropriate adaptor as any other digital signature, affording adaptors marked efficiency and confidentiality improvements over hash locks. In the Lightning Network, signature adaptors are generated for each hop in a route such that no two hops use the same adaptor. However, they are all linked because the second adaptor (Tb), for example, commits to the first (Ta), and so forth. Hence, the payment's original signature and committed secret are kept confidential.
How PTLC has improved upon HTLC
- Improved Privacy
Due to the decorrelation of payments in PTLCs, there is improved privacy. How so? Unlike HTLCs, which share the same preimage digest, PTLCs bind funds to payment points on Bitcoin's secp256k1 curve, which we can compute in the same way as on-chain public keys. A new key (also used to produce a new signature adaptor) is linked to the original payment point for each hop in a payment route, rendering the original payment point anonymous to the current hop. Another benefit of privacy is that even after the proof of payment has been settled, only the receiver (who creates the secret) and the sender (who initiates the payment) eventually learn about the secret, making the payment unlinkable even when broadcast on-chain.
- Stuckless payment
Although this is not a regular problem with HTLCs, it does occur occasionally and can result in funds being locked up and unavailable until the time-lock expires. A stuck payment is one in which a node does not receive his or her payment refund until the time-lock expires. This may occur for a variety of reasons. One of them is that a bad node might hold your payment hostage at no cost to them using HTLCs (other than forgoing the fee that they could be paid for the use of their channel).
However, with PTLCs, this is avoided since the receiver must send an ACK message to the payer before the settlement phase (payment of funds in the route) begins, proving that the payment was not stuck during setup. Only after receiving an ACK is the setup completed, at which point the payer sends the required signature adaptors, to which the recipient responds with proof of payment as she has now been properly paid. Finally, as is conventional, settlement occurs. This is unique in that the intermediary hops do not require proof of payment, only the payment's end nodes. This concept is illustrated in the update phase of the diagram below.
It's important to note that the Proof of Payment (PoP) is not the same as the payment secret generated by the recipient. In HTLC, the proof of payment is basically the preimage. This article has more information on stuckless payment using PTLCs.
How PTLCs Work
There are 3 main phases in PTLCs.
(i) a setup phase,
(ii) an update phase and
(iii) a settlement phase.
Let's take a quick look at these stages and see how they're linked. We'll suppose that Alice wishes to pay Carol for an item (say, a wristband) that she purchased with lightning PTLCs.
The diagram illustration below should serve as a guide in explaining these stages.
- Setup phase
Carol begins by creating a payment invoice. She accomplishes this by binding the payment to a secret (z) (or private key). She then creates an invoice for Alice by producing a public key (z*G) from the secret (rather than a hash of the secret as in HTLCs) and sending it to her. The payment point is the public key generated in this case.
Carol begins by generating a payment invoice. She accomplishes this by associating the payment with a secret (z) (or private key). She then creates an invoice by producing a public key (z×G) from the secret (rather than a hash in HTLCs) and sending it to Alice. The payment point is the public key that has been generated.
After that, Alice creates an HTLC-like contract, but this time the payment is related to the distinct random numbers for each hop. She sends Bob a contract stating that if he provides the private key connected with (a + z)×G, which is effectively (a + z) representing Alice's first random number tied to the payment point, he will earn bitcoin. Alice, on the other hand, offers Bob 'b' so that he may compute (a + z) × G + b × G, which equals (a + b + z), and so Bob can compute (a + z).
By employing a distinct random number for each hop, this approach can be extended to an arbitrary number of hops. As a result, each hop has a separate and distinct condition (due to the addition of a random number each time), and this brings payment decorrelation! A new signature adaptor is also generated for each hop in the route, which commits to the previous adaptor in the route.
When Carol receives a contract from Bob, she sends Alice an ACK message to finish the setup phase. Carol will be paid if she can supply the private key associated with (a + b + z)×G, according to the contract. This ushers us into the next stage of the process.
- Update phase
When Alice receives Carol's ACK message, she sends Carol the sum of the payment point and the random number (a + z)G. Because each hop should now hold the sum, this serves to update the payment. However, because Carol is the only one who knows the secret z, the settlement of payments will begin with her. It's worth noting that knowing Alice's sum doesn't necessarily imply that you can compute the individual numbers a and z. Because of the way Bitcoin's elliptic curve addition works, this is a unique feature. As a result, the intermediary nodes are unaware of the secret z and random number a.
The purpose of the ACK message is to demonstrate that the payment did not become stuck during setup. If no ACK message is received, Alice can infer that one of the nodes is down or something, but her payment funds are still safe because she hasn't exposed the sum (a + z)×G to Carol, which is required for all hops to collect their payments.
- Settlement phase
This is the final phase where Carol and other intermediary nodes get their payment. Carol gets her payment because she can compute (a + b + z)×G and Bob gets his because he can compute (a + z) × b×G. Finally, Alice receives her PoP since she can compute z from (a + b + z)×G. With this, only Alice and Carol know the secret, z, thereby improving privacy. Although the setup appears to be complicated, we can see that employing PTLCs allows us to make payments on the Lightning Network in a more efficient, secure, and private manner.
Lock setup
As a bonus, let's go over the PTLC lock set briefly. More details on this can be found in the Github ReadMe.
A PTLC lock is a tuple (Li, yi, Ri) consisting of:
Left lock (Li) = z × G (where z is a secret/private key)
yi = scalar uniform random number
Right lock (Ri) = lock for each node (i)
For the first hop we generate a PTLC as shown in the diagram below:
This setup. is used for the different random numbers generated for each hop. However, only the right lock gets sent to the next hop.
We'll explore the similarities to HTLCs and issues with PTLCs in the next article.
Reference