In the last article, I wrote about what PTLCs are, how they improve on HTLCs, and gave technical examples showing their intricacies and arguing their benefits. This article will explore how similar PTLCs are to HTLCs, as well as some problems associated with PTLCs and potential fixes for them.

Similarities between PTLC and HTLC

• Atomicity

Both HTLCs and PTLCs have the property of atomicity in payments. This is an important and unique feature of the Lightning Network. It means all payments at each hop in a route either all succeed or all fail. Either the payment is fully executed, or it fails and everyone is refunded. There is no possibility of an intermediary collecting a routed payment and not forwarding it to the next hop. Thus, the intermediaries can’t cheat or steal.

This is important because one of the more difficult issues for Lightning Network nodes is that it becomes progressively more difficult to route payments as the size of the payment increases due to channel liquidity constraints. Furthermore, the parties involved in a payment cannot use their money while it is locked in the contract. Thus, users forwarding payments face an opportunity cost for (temporarily) locking their money, which is ultimately reimbursed through routing fees. The time-locked nature of Lightning Network payments addresses this issue, giving rise to atomicity in said payments. So if for any reason the payment fails, all nodes in the route get a refund, and if successful, they get their payments.

• Time lock condition

From their names, it is obvious that both HTLCs and PTLCs have a time-lock feature. What this means is that the contracts are constructed such that a time lock is attached. This is necessary because if there's an issue with the payment along the route, the sender doesn't have to wait until the issue is resolved before the payment is processed.

Let's illustrate using our Alice to Carol example from the previous article. As an intermediary hop, if Bob's node goes offline while routing the payment, without a time lock, Alice's funds will get stuck up until Bob's node comes back online or even get stuck forever if Bob’s computer breaks. However, with the time lock feature, the payment can only be delayed by Bob's for the duration of the time period specified in the contract, after which a refund is given to Alice when the time expires and if Bob's node doesn't eventually come online.

• Multihop security

This basically means that there is ambiguity in-between the hops in a route. The hop before and after a node does not know where the payment originated from or is going to. This is possible because of the onion layering of hops in the Lightning Network. The security of the system extends end-to-end for payments routed through multiple payment channels, just as it is for a payment between the two ends of a single payment channel. Since this is a protocol level feature, both HTLCs and PTLCs adopt the multihop feature.

• Trustless operation

Either with HTLCs or PTLCs, the participants in a routed payment do not need to trust each other, or any intermediary or third party. Instead, they trust the protocol to protect them from cheating.

---

Issues with PTLC

It is generally acceptable to say that no protocol or technology is flawless in its design today. As far as I know, there's only one issue with PTLCs - Cycle jamming.

• Cycle jamming

Cycle jamming is possible in PTLCs because they allow payment decorrelation - which means that nodes in a multi-hop lock can not determine (absent timing and coin amount analysis) if they are on the same path, i.e. two nodes don't know if they are forwarding the same payment.

A post by bitcoin problems describes this issue clearly: "In Point Time Locked Contract (PTLC) based Lightning channels the lock is randomized at each hop so that two malicious nodes separated by at least one honest node in a payment path cannot use the lock to determine whether the PTLCs are part of the same payment. Unfortunately, this seems to make PTLCs a little bit too unlinkable – it allows a malicious sender to create a single payment that cycles multiple times through a target pair of honest nodes significantly reducing the capacity between them for a small cost to the attacker. As in an ordinary jamming attack the malicious receiver then refuses to unlock the payment leaving the funds locked along the path until timeout. The honest nodes cannot detect the attack for the same reason that it preserves privacy: each incoming PTLC cannot be linked to any previous one."

Potential fixes

Solving the cycle jamming attack would ensure that PTLC payment decorrelation won't affect the Lightning Network.

Currently, no solution has been found for the cycle jamming problem. However, potential fixes include:

• Proof that payment path is cycle free

If there could be a way for nodes to determine if a payment route is cycle-free, this could be a possible solution. This needs to be done when computing the paths for making the payment in the setup phase. This has not been experimented upon; hence, the theory lacks details.

• Lock more of sender’s fee

Although this comes at a cost to the sender, by locking more of the sender's funds, a malicious sender node might be discouraged from carrying out a Dos/cycle jamming attack.

Conclusion

From the first and second articles in the series, we see that PTLCs are a promising upgrade to HTLCs. However, there is little adoption, which is mostly experimental. Another reason for low adoption is that efficient implementation of PTLCs depends on a new digital signature algorithm called Schnorr signatures, which is a somewhat complex implementation for people to understand. Also, for PTLCs to be widely adopted, all nodes in the path require an end-to-end upgrade along the path because, currently, you cannot mix routes with PTLCs and HTLCs.

With time, though, it is expected that PTLCs will become widely used in the Lightning Network for making payments. Until then, HTLC is king.

Attribution

Many thanks to Will Clark and Duncan for the reviews of these two articles.

Resources

• bitcoinproblems.org/#:~:text=PTLC%20Cycle%2..

• Mastering Lightning book