PTLCs
A core function of Lightning is the ability to send bitcoins across channels offchain and HTLCs (Hashed and Time Lock Contracts) are what makes that possible currently. I explained how they work in-depth here, you should check it out. I would explain in this article the current downsides of HTLCs and what PTLCs are and how they fix the problems HTLCs create, and also a potential problem PTLCs bring and proposed mitigations for them.
HTLC drawbacks
HTLCs are locked using a hash digest and are unlocked by providing the corresponding pre-image. When this is used to route payment through a number of channels, all payments use the same pre-image and hash lock. This creates a link between the payments if they’re ever published onchain or if they’re routed offchain through surveillance nodes. This also means that two nodes sharing information by belonging to the same person for example can find out they are in a route together by seeing that they have received HTLCs with the same hash which could potentially lead to a “wormhole attack” that sees them working together to steal the fees of the intermediate nodes between them. You can read more about it here.
HTLCs also introduce cycle jamming attacks, which are Denial of Service (DoS) attacks and are essentially where an attacker can prevent a series of channels from being able to use part or all of their funds for a long period of time and the way this could be set up is that two nodes working together could route payment through several channels to each other and refuse to reveal the pre-image of the hash thereby denying subsequent nodes used to route payments the ability for them to claim their funds and gets them tied up in the HTLCs until they time out.
The Solution: PTLCs
Point Time Locked Contracts (PTLCs) are locked using a public key and unlocked by providing a corresponding signature from a satisfied signature adaptor. Signature adaptors are signature data that commit to a hidden value, so when an adaptor is combined with a corresponding signature, it reveals the hidden value. Also, when an adaptor is combined with the hidden value, it reveals the signature. Other people can create secondary adaptors that reuse the commitment even without knowledge of the hidden value. This makes adaptors a powerful tool for implementing locking in bitcoin contracts and is what PTLCs are built on. You can read more on signature adaptors here. In HTLCs, contracts are locked by having a value hashed then unlocked by revealing the pre-image to the hashed value and then time locked while the way PTLCs work is that a point lock is locked using a public key which is a point on Bitcoin’s elliptic curve and unlocked by providing a corresponding signature from a satisfied signature adaptor
Get Abdulhakeem Abdulazeez’s stories in your inbox
Join Medium for free to get updates from this writer.
Each point lock in a PTLC can use different keys and signatures, so nothing about a point lock can be used to link other locks in the same payment route. This effectively solves the payment link problem with HTLCs. The same mechanism that brings about this solution introduces its own problem known as cycle jamming which will be discussed further below.
PTLC Upsides
a and b are scalars and each one multiplied by G, the fixed point on Bitcoin’s elliptic curve, gives you its public key. Adding two public keys will give you the public key of the two sclars added together. Everything else is built on this. Hashes scramble their inputs so its impossible to add them up.
1. Stuckless Payments
In the Lightning Network currently, payments can get stuck in a channel either during setup or during settlement and a malicious node could be behind this. It is also not advisable to retry the payment because you run the risk of paying twice should the first payment eventually go through. With PTLCs, during setup, Carol sends an ACK to Alice to confirm that the setup is complete, and only then will Alice share the final piece of the key with Carol so she can claim her payment from Bob. This is the update phase that gets introduced to mitigate the stuck payment problem. The payoff here is that Alice can try several routes at once and only release the piece for the one that arrives, so she never pays twice.
2. Escrow Smart Contracts
Arbitrary smart contracts can be supported in Lightning if payment points are used and the general idea is that Alice and Bob choose to enter a contract and Erin is the trusted escrow. Alice computes a secret that only she knows but Erin can derive it if she learns Alice’s public key A. This secret Alice computes combined with Bob’s key is what unlocks his payment. If Alice is happy with Bob’s service she then reveals the secret and he can get to complete the payment. If Bob doesn’t perform the service he never learns what the secret is and doesn’t get paid. Now if either of the parties choose to be malicious and say Bob completes his service and Alice refuses to tell him what the secret is, Bob can then involve Erin and reveal Alice’s public key to Erin and then Erin can compute the secret then if she judges that Bob completed his services, she reveals the secret to him so he can get paid and if she judges that Bob did not do his service, then the lock times out and Alice gets her funds back.
3. Selling Signatures
You can buy data on Lightning but it is not completely trustless because you need to trust that the seller will send what is expected since the buyer has to pay before it gets sent and there is no way of validating the data before it gets received. Payment points fixes that. Every Schnorr signature s satisfies s·G = R + e·P, where R is the public nonce, P is Bob’s public key and e is a hash of R, P and the message. The right hand side of this equation is all public so the buyer can compute the lock and only the exact signature can be used to unlock it. Practical uses for this are ecash, anonymous credentials, and peer to peer options contracts.
Cycle Jamming
PTLCs unique property of randomizing locks at each channel hop to increase privacy by making routed payments unlinkable unfortunately happens to make the cycle jamming attack more difficult to notice, and this happens where a malicious sender can create a single payment that cycles through a target pair of honest nodes multiple times to reduce the capacity between them and then the malicious receiver would refuse to unlock the payment locking the funds until they are timed out. Honest nodes in this case cannot detect the attack because of the privacy preservation: two nodes don’t know if they are forwarding the same payment.
Potential Fixes
- Proof that payment path is cycle free:- A way to determine that the payment path does not cycle through a node repeatedly would solve the cycle jamming problem and this needs to be done when the path is being computed in the setup phase. It is all still theoretical as things stand.
- Lock more of the sender’s funds:- This would come at a cost to the sender but it’s aim is to discourage a malicious node from carrying out a cycle jamming attack.
Conclusion
HTLCs made lightning successful, not without its downsides. And PTLCs aim to fix those downsides and we have see how from above, but PTLCs also come with its own downsides, which fixing it would mean PTLCs could then be integrated into the protocol and hereby make Lightning even better with these new fixes and updates.
