zkChannels for Bitcoin
Today, we proudly present zkChannels, a layer two protocol that enables privacy-preserving, off-chain Bitcoin and Zcash payments between customers and merchants. The protocol implementation is available on Bitcoin’s simnet and private testnet.
The initial zkChannels v1 protocol released today was originally called BOLT. BOLT was inspired by the Lightning Network and enables private payments via zero-knowledge proof of knowledge techniques, with cryptocurrencies like Zcash and Bitcoin in mind. However, the initial design required changes to be made to the underlying cryptocurrency in order to support the BOLT functionality. We redesigned the protocol to avoid this drawback by leveraging multi-party computation (MPC) techniques; we have implemented our new version on Bitcoin, but the protocol itself can be instantiated on any Bitcoin-like cryptocurrency.
zkChannels offer strong anonymity and unlinkability properties for off-chain transactions using MPC techniques. Customers can transact anonymously with Bitcoin without revealing their identity to a merchant. Moreover, the merchant cannot link two payments as having originated on the same channel. In the existing Lightning protocol, a customer’s identity is long-lived and there is no privacy between a customer and merchant by default. It effectively works like a cookie on websites. Our protocol addresses this problem.
Combined with an anonymous credentials scheme, zkChannels unlocks privacy-preserving authentication for unlinkable payments so that users can pay for a service without the usage of the service being linked to their identity. Our protocol fundamentally decouples the customer’s identity from the service itself. Adding privacy makes payment channels suitable for VPN access, online video purchases, and much more. More broadly, we believe zkChannels will become a new standard for security and privacy in online services compatible with the existing web architecture and emerging privacy regulations like GDPR.
High-level Protocol
Disclaimer: Our description of the zkChannels high-level protocol is a simplified version for the purposes of this blog post. The low-level design details will be available in our forthcoming academic paper.
Lightning allows for faster payments than Bitcoin, therefore allowing payments for online services and web content. In practice, this means users pay the service with Lightning channels in order to get an authentication token which can be used later to access the service. Unfortunately, individual payments are still linkable to the customer’s usage of the service, thereby compromising their privacy. Our zkChannels design achieves the same goals as Lightning while also preserving privacy.
Much like Lightning, zkChannels allow a customer and a merchant to open a bidirectional payment channel. Unlike Lightning, in zkChannels the two parties have different views of the channel’s state. Specifically, in zkChannels, only one party (i.e., the customer) knows the channel balance and the identity of the second party (i.e., the merchant). To the second party, the only knowledge conveyed during a payment is the fact that someone with an open channel made a payment for a certain amount. Nonetheless, this protocol ensures that channels can be closed down at any time by either party, either unilaterally or by mutual agreement.
To preserve privacy, zkChannel data is kept asymmetrically. The customer keeps all relevant channel update information and proves, every time a payment is made, that the current channel state is consistent with that payment. This ensures the merchant learns nothing and privacy is maintained.
All payments in zkChannels are initiated customer-side; payment values themselves can be positive or negative, hence bidirectional payments are supported. More specifically, the channel can be viewed as a sequence of states: at any given time, the customer holds a signed closing transaction for the current state and a fresh, unlinkable payment token for that state. The customer can choose, at any time, to either make a payment or close the channel down by posting their most recent closing transaction on chain.
If the customer makes a payment, the customer spends their payment token and receives a fresh, signed closing transaction on the new state in return. The customer, confident that they can close down the channel on the new balance if needed, then invalidates their old closing transaction by revealing a corresponding revocation secret. As soon as the merchant receives a valid revocation secret for the old state, the merchant is confident that the payment is complete and issues a fresh payment token to the customer.
Payment tokens and closing transaction signatures are issued using secure multi-party computations (MPC). MPC protocols are a cryptographic tool that allows parties to jointly compute a function over secret inputs while minimizing trust, preserving privacy, and guaranteeing correctness. In the context of anonymous payment channels, we are using two-party secure computation techniques to blindly compute ECDSA signatures on Bitcoin transactions. As such, from the merchant’s perspective, no specific information about the payment is revealed other than the amount. The MPC guarantees the correctness of the payment to the merchant. Specifically, it guarantees that the payment was initiated using a valid, unspent payment token on an open channel of sufficient balance. Additionally, each payment results in enough information that the merchant can prevent double-spending of payment tokens, and can recognize and dispute if a customer posts an outdated closing transaction on chain. If an on-chain dispute occurs, a cheating customer forfeits any remaining balance in the channel to the merchant as punishment.
As with other layer two solutions, our closing and dispute mechanisms require that both parties be online or designate a third party (e.g., a watchtower service) to track transactions related to their open channels. A unilateral close by either party triggers a dispute period of up to two weeks: if the merchant closes a channel, the user must respond by posting their own closing transaction with the correct channel balances before the dispute period is over, or all the money in the channel goes to the merchant. Similarly, if a customer tries to close with an outdated closing transaction, the merchant has to use their revocation secret before the dispute period is over.
Building Blocks
The cryptographic techniques employed in zkChannels are based on Yao’s garbled circuits protocol, hash-based commitments, and using MPC to achieve blind ECDSA signatures for Bitcoin transactions. For our initial implementation, we build on the Efficient Multi-Party (EMP) computation toolkit — a general-purpose compiler that allows defining arbitrary functions using a subset of C and executes secure computation protocols. If you are interested in more technical details, read our introduction on secure MPC techniques here.
Implementation
We have released a proof-of-concept libzkchannels library in Rust that consists of the core functionality for establishing a channel, anonymously updating the off-chain state via secure MPC, and closing the channel. We have integrated this library as an extension of the Lightning Network Daemon (LND) developed by Lightning Labs. Our version is called zkLND. You can take a look at the protocol overview here and test it out by following the tutorial.
Current Limitations
A few limitations of our initial release are as follows:
(1) Linkability of ECDSA signatures to issuance during channel close. The MPC outputs ECDSA signatures, which are not randomizable. As a result, the last payment made on a channel can be linked to channel closure if a merchant chooses to track the necessary signing state given to the MPC during Pay sessions. We look forward to revisiting this issue when Schnorr signatures are adopted on the Bitcoin mainnet.
(2) Optimizing performance in the malicious security model. Our current MPC implementation is secure against a strong adversarial model that offers more robust security guarantees against malicious adversaries. That is, our MPC functionality is secure against adversaries that do not necessarily follow the protocol and may try any arbitrary attack strategy in order to deanonymize the users, link payments, or corrupt the MPC outputs. Security in this model means that despite the attack strategy, users either get correct output from the MPC or no output (e.g., due to an abort). This strong guarantee is necessary for production deployment but also has significant performance drawbacks. For instance, the time to execute the MPC takes about 7–9 seconds on average on a modern workstation (not including network latency). There are a number of optimizations we are investigating to speed up computation in this model.
(3) Routing via an untrusted intermediary. Our protocol does not currently support forwarded payments, but we plan to release a version that allows the use of an untrusted intermediary.
(4) Third-party watchtower support. The asymmetric nature of zkChannels means that existing third-party watchtower implementations may not be directly compatible with our approach. We plan on extending to third-party chain watchers in the near future so that users are notified of channel closure events instead of being responsible for scanning the entire blockchain at all times.
(5) Lack of privacy at Layer 1. Channel opening and closing are visible on the Bitcoin network. It is possible to mix UTXOs via CoinJoins to obfuscate channel openings, but this is out of scope. With Zcash, we are able to implement an end-to-end solution via shielded transactions.
What’s Next?
zkChannels offer a fundamental building block that enables unique privacy-enhancing products. As we expand to other currencies and smart contract platforms, we will be able to support cross-chain token transfers. With support for routing via an untrusted intermediary, we can build an off-chain network that connects exchanges, banks, and custodians in a trustless and truly privacy-preserving way using zkChannels.
In the near future, we will be releasing an academic paper, extensions to zkChannels that address some of the current limitations, and a Zcash public testnet in collaboration with the ECC that supports our protocol. If you are interested in learning more, please reach out to us at info@boltlabs.io.
Special thanks to our advisors and team for proofreading and providing valuable feedback on this post. This includes Colleen Swanson, Marcella Hastings, Darius Parvin, Gijs Van Laer, Howard Wu, Kartik Talwar, Linda Xie, Dmitriy Berenzon, Matthew Green, Ian Miers, Moses Icyishaka, and TJ Abood. Finally, thanks to Darren Mills for assistance with creating the diagrams in this post.
