Hash Time-Locked Contract Issues
The Lightning Network, as it is today enables payment routing by using the Hash Time-Locked contract, the HTLC. In simple terms, this contract enables the network’s trustless, atomic routing of payments by guaranteeing that the sender commits to sending money to the receiver only if the receiver reveals a secret that generates a specific hash. If the receiver doesn’t reveal the secret then the sender can get its coins back after a specific period.
If you read our blog post about privacy on the Lightning Network, you might already know this, but there’s a privacy issue with the HTLC: it enables payment correlation. Since every payment in the lighting network has exactly one payment hash associated with it, an attacker that controls more than one node in a payment path can be 100% sure that it is routing the same payment if the payment hashes that it sees in both nodes matches.
For the payment in the image above, for instance, the attacker sees the same payment hash both in the Hop #1, and Hop #3 nodes. Although onion routing hides the number of hops in payment from the intermediary nodes, every intermediary node knows who sent the payment to them and who they need to send the payment to. This means that the attacker knows that Alice, Bob, and Hop #2 were involved in the same payment. This same technique can be used to steal fees from intermediary nodes through an attack known as a wormhole attack.
Another issue with HTLCs is that if any scripts are published on-chain, they stand out from regular spender scripts, making it simpler for surveillance to detect usage patterns and potentially deduce information unique to individual users, as we’ve discussed in the “How Private is the Lightning Network” article.
Point Time-Locked Contract
Given the vulnerabilities listed in the previous section, it makes sense to research alternatives to HTLCs that address the issue of payment correlation. One such choice became possible after the last Bitcoin soft-fork, which enabled Schnorr signatures and Pay-to-Taproot scripts, the Point Time-Locked Contract, or PTLC. These contracts rely on adaptor signatures, a variation of Schnoor signatures.
Schnoor allows more flexibility to create and use multisignatures when compared with the classic digital signature algorithm used by Bitcoin since its creation, ECDSA. It enables key aggregation, where multiple parties can combine their keys in a single key simply by adding them together. Adaptor signatures, in turn, are a mechanism that creates auxiliary signatures that commit to a hidden value. When an adaptor is combined with a corresponding signature, it reveals the hidden value. Schnorr signatures make it easy to compose those adaptor signatures with multisignatures.
Remember, the happy path of an HTLC is the one in which the receiver must reveal a secret for a hash it provided to spend the money locked in the HTLC. PTLCs replace this mechanism with adaptor signatures and combine it with clever key aggregation to create an alternate clause for redemption. They require that the receiver reveal a private key (the hidden value) to a specified public key to claim the funds. The basic idea is that each party creates a secret value that is used to generate a partial signature. These partial signatures are then exchanged between the parties, who can combine them to create a complete signature for the transaction.
Suppose Carol creates an invoice for Alice to pay. She starts by giving Alice a public key for her secret private key. Alice now requests a public key from Bob and creates an adaptor signature using the aggregation of both Carol’s public key and Bob’s public key, which she gives to Bob.
Bob knows his public key, and consequently, his private key, therefore he’s able to subtract that from the adaptor he receives from Alice, getting a new public key from the subtraction, which is now just the public key that Alice originally received from Carol, but Bob doesn’t know that.
Finally, Bob constructs an adaptor signature using the public key he generated and gives it to Carol. Carol knows the private key for the final public key and can convert Bob’s adaptor signature into a valid signature. Bob now can recover Carol’s private key from her signature and uses it with its own private key to convert Alice’s adaptor signature into a valid signature.
Note that, with PTLCs, the valid signature enables each party to claim the locked coins in the contract. Also, two public keys were used in the two hops in this path, eliminating linkability. Any party that tries to retrieve information about a payment by controlling more than one node in a payment path cannot do so because each PTLC is bonded to a different secret.
As a bonus, if any of the PTLCs is broadcasted on-chain, they would only reveal valid signatures for distinct public keys, making this lightning payment indistinguishable from single-sig payments, standard multisignature payments, and cooperatively resolved contracts, therefore protecting lightning nodes from on-chain surveillance.
By now you might be wondering where the name “Point Time-Locked Contract” comes from. The name is derived from the way public and private keys are represented. Points on a curve represent public keys, and private keys are regular numbers that yield a point when multiplied by a generator point.
Protocol Changes
PTCLs would require adoption by the network to work properly since they can only be used when the whole route supports them. This is because more signatures need to be exchanged between peers when compared to HTLCs. Note how, when using PTLCs, Bob needs to send adaptor signatures to Alice in the “Commitment Proposed” message before she can send the “Commitment Signed” message.
Besides solving the linkability issue, PTLC transactions are smaller than HTLC transactions, which means that PTLCs minimize the use of block space and pay fewer fees. Also, since PTLCs use Pay-to-Taproot scripts, the refund conditions offer more privacy as they are indistinguishable from various possible other scripts.
Other use cases
Stuckless Payments
When using HTLCs, a payment attempt can become stuck and neither fulfilled nor canceled due to various reasons such as a bug on an intermediary node, a node going offline while handling HTLCs, or a malicious node withholding HTLCs without reporting an error. The sender only gets its money back when the HTLC’s timelock expires, which can tie up the funds committed to that HTLC and cause inconvenience to the sender who must wait until expiry. Moreover, the sender cannot retry the same payment, as it may result in the recipient receiving the two amounts.
This issue can be solved using stuckless payments, a proposal by Hiroki Gongo that relies on PTLCs, and the addition of an extra round of communication during the setup and settlement of the payment. When using this method, senders can safely retry payments if they become stuck. They can also retry their payment along another route and even start more than one payment attempt using different routes simultaneously, ensuring that if one of the payments succeeds all others will fail.
Escrows via Lightning
A non-custodial on-chain escrow protocol is a contract that involves a 2-of-3 multisig arrangement between two participants and the escrow. Although such a contract can be transported over a single Lightning channel, it cannot be safely transferred across channels.
Escrow services are particularly useful when Bitcoin needs to interact with other systems, such as the real world, where trust is difficult to obtain. In simple terms, an escrow is a contract that involves three parties, namely Alice, Bob, and Carol, who acts as a trusted escrow. Such contracts can be utilized for various purposes that require the attestation of Carol’s trustworthiness. The developer known as ZmnSCPxj proposed on the lighting mailing list to enable routing escrows over the lightning network using PTLCs.
Concluding
The HTLC used in the Lightning Network has some privacy vulnerabilities that enable payment correlation and can potentially reveal information unique to individual users. However, the newly possible Point Time-Locked Contract (PTLC) offers an alternative that addresses the issue of payment correlation by using adaptor signatures and clever key aggregation. With PTLCs, each party creates a secret value that is used to generate a partial signature that is exchanged with the other party, and then combined to create a complete signature for the transaction. This eliminates linkability, protects lightning nodes from on-chain surveillance.
Additionally, the benefits of PTLCs extend beyond addressing privacy vulnerabilities in the Lightning Network. One notable use case is “stuckless payments,” which enables multiple payment attempts simultaneously. Another potential use case is the routing of escrow contracts over lighting.
Create your own node below, or learn more about our Lightning Enterprise solution today.
Also, enjoy exploring our LSP Flow or testing our time series data tool Surge.
