How Taproot Improves The Lightning Network

January 3, 2022

Changes to the Bitcoin protocol are like pebbles dropped in a lake. They may be imperceptible initially, but their effects can ripple throughout the ecosystem and eventually change the user experience fundamentally.

Just as the Segwit upgrade simultaneously alleviated the urgent issue of block space and enabled the launch of the Lightning Network by fixing transaction malleability, Taproot's improvements to the Bitcoin protocol have immediate implications while laying the foundations for future improvements.

This article will discuss these improvements, particularly how they affect the Lightning Network's efficiency, privacy, and useability. We'll start by giving some background on how scripting works in Bitcoin and how Taproot enhances it.

We'll then explore the implications of Point Time Locked Contracts (PTLCs) on privacy namely, how channel openings can be hidden and payments can be connected.

Finally, we'll glimpse how we can expect better useability by introducing stuckless payments, which also rely on PTLCs.

What does Taproot do?

You might be surprised that Bitcoin even has a scripting language. It does, and it's called, wait for it, Script. All transactions in the Bitcoin network require the evaluation of some script, ranging from the simplest transaction whose validation requires an unlocking script to allow the spending of the Bitcoin to more complex smart contracts such as multi-signature wallets.

Taproot combines three Bitcoin Improvement Proposals (BIPs) that enhance this scripting infrastructure: BIP340 - Schnorr, BIP341- Taproot and BIP342 - Tapscript. The key of Taproot that unlocks all the others is the introduction of Schnorr Signatures, which allow for key and signature aggregation. This means that multiple parties can combine their keys to a single public key, thereby allowing them to sign a single message.

For those who know a bit about how the Lightning Network works, this should be ringing some bells since Lightning channels are comprised of 2 of 2 multisigs.

A conceptually straightforward implication is that it makes channel openings cheaper. Remember that the transaction fee is not related to the amount of bitcoin one sends but rather, the complexity of the transaction determines the cost. Each block is only 1 MB so it doesn't matter how much you send but rather how much data of the mempool you take up with your transaction. Aggregating signatures means that we have lighter transactions and therefore cheaper channel openings.

Signature aggregation also offers enhanced privacy since its contents are indistinguishable from a single-signature transaction. Does this mean that lightning channels are now unidentifiable on the blockchain? The answer is 'yes' for private channels and 'not quite yet' for public channels. We’ll find out why in the next section.

The Promise of Privacy pt1: Hidden channels

Ideally there would be a separation between blockchain transactions and lighting payments so that lighting users wouldn’t be compromised by any potential privacy leaks from the funding transactions and vice versa.

Funding transactions execute a 2 of 2 multi-sig script which is fairly easy to spot on the blockchain as of today. As mentioned above, the introduction of Schnorr signatures means that we can aggregate multiple signatures into a single signature, making channel openings indistinguishable from standard transactions.

Unfortunately, even if we hide the channel openings on the blockchain, the current specification of the lightning protocol requires nodes to broadcast the details of the funding transactions when announcing their channels.

This might initially seem counterintuitive, but it’s also an elegant way to prevent nodes from spamming the network with fake channels. In the most literal sense, it’s proof of stake, proof that a node has staked some Bitcoin.

The good news is that private channels aren’t advertised on the network, so they reap the benefits of Schnorr Signatures. In addition, discussions are underway to update the Lightning protocol to allow nodes to advertise their channels in a more privacy-preserving way.

The Promise of Privacy p2: Payment Decorrelation through Point Time Locked Contracts (PTLCs)

Another potential surveillance vector for Lightning payments is that payments are associated with a unique and static payment hash. This payment hash is sent from the recipient to the sender, which is shared with nodes on the route to represent the payment. If sybil nodes were surveilling the network, and it would be wise to assume so, they could coordinate and map payments. With enough hostile nodes, a fairly detailed picture of the flow of funds could be painted.

Taproot's introduction of Schnorr signatures paves the way for a smart contract called Point Time Locked Contracts (PTLCs). PTLCs operate similarly to HTLCs by allowing payments to be identified by nodes. Still, PTLCs come with a handy feature of randomizing its identifier with each hop, making it impossible for nodes to correlate the traffic of sending and receiving nodes.

PTLCs and Stuckless Payments

Stuck payments represent a serious UX problem. Users can become confused frustrated and potentially even lose their funds. Payments can get 'stuck' by something as simple as communication being lost between nodes on the route or something more sinister like a malicious node withholding a payment.

When payments are stuck, the sender needs to wait for the HTLCs to timeout for the funds to be reimbursed. It is also not advised to retry the payment as it may result in a double payment. As Hiroki Gondo notes in the Bitcoin dev mailing list: "The payer cannot obtain the information to prove he has paid twice (he has only a single preimage).".

In the same email, Gondo proposes a method to prevent stuck payments using PTLCs by introducing a new phase that requires the receiving node to acknowledge a PTLC from the sending node once a route has been found. This signals to the sending node that the payment didn’t get stuck. For the payments that did get stuck, the sending node would never receive this acknowledgment message (the timeout could be set to a minute or so) and would know that it is safe to retry the payment with another invoice.

It's useful to note that it doesn't require all the nodes in the route to be upgraded to handle the update phase as it is only communicated between the sender and the receiver. The acknowledgment message can be stuffed into the 'reason' field of the bolt invoice that the nodes will pass on without dealing with it. The details of this mechanism may be elaborated upon in a future article.

Conclusion

Taproot allows for both quick wins and longer-term improvements to the Lightning Network. In the short term, the introduction of Schnorr signatures allows for cheaper channel openings as multi-sig signatures are now smaller and decoupling the opening of private channels from their blockchain transaction. We may also see stuckness payments come into play as it require only the sending and receiving node to upgrade to PTLCs.

We will need to wait for some changes to the lightning protocol to bring the same amount of privacy to channel openings as private ones and payment decorrelation, as it requires PTLCs for all nodes on the route. Still, the groundwork is there, and discussions are currently underway. Taproot is a door that opens many other doors. A big thanks to the protocol developers in opening this one up and for the work on opening up all the others that may follow.