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.