Back to the Blog

How Taproot Improves The Lightning Network

Bitcoin Education

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

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.

In this article we’ll walk through these improvements, in particular how they affect the Lightning Network in terms of efficiency, privacy, and useability. We’ll start off by giving some background on scripting works in Bitcoin and how it’s enhanced by Taproot.

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 decorrelated from each other.

Finally, we’ll wrap up by giving a glimpse into how we can expect better useability through the introduction of stuckless payments, which also rely on PTLCs.

What does Taproot actually 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 is a combination of 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 are able 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 as we know 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, it’s the complexity of the transaction that 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? Well, 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 multisig script which, as of today, are fairly easy to spot on the blockchain. As mentioned above, introduction of Schnorr signatures means that we are able to aggregate multiple signatures to a single signature thereby making channel openings indistinguishable from standard transactions.

Unfortunately, even if we do 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 seem counterintuitive at first, but it’s also an elegant way to prevent nodes 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 the fact that payments are associated with a unique and static payment hash. This payment hash is sent from the recipient to the sender, and it is this hash that is shared to nodes on the route to represent the payment. If there were sybil nodes 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 type of smart contract called Point Time Locked Contracts (PTLCs). PTLCs operate in the same manner as HTLCs by allowing payments to be identified by nodes, but PTLCs come with a handy feature of being able to randomize its identifier with each hop thereby 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 it means that 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 goes on to propose 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 acknowledgement 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 acknowledgement message can be stuffed into the ‘reason’ field of the bolt invoice that the nodes will pass on without having to deal with it. The details of this mechanism may be elaborated upon in a future article.


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 multisig signatures are now smaller as well as decoupling the opening private channels from their blockchain transaction. We may also see stuckless payments come into play as it requires only the sending and receiving node to upgrade to the use of PTLCs.

We will need to wait for some changes to the lightning protocol to bring both the same amount of privacy to channel openings as private ones as well as payment decorrelation as it requires PTLCs for all nodes on the route, but 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.


If you have any questions or comments either email us at, use our live on-site chat, or join us in Discord. ⚡️