Revoke and Update: A More Flexible Payment Protocol for Payment Channel Networks

Abstract

Payment channel networks (PCNs) are a promising solution to the blockchain scalability problem. They move payments off-chain, i.e., not all payments have to be included in the blockchain. Thus, they do not require that every payment is broadcast to all participants and verified by them. Not requiring global consensus reduces latency, computation, and hence energy consumption.

In PCNs, a payer can route a multi-hop payment to a payee via intermediaries. Yet, Lightning, the only prominent payment channel network, has two major issues when it comes to multi-hop payments. First, the payer decides on the path without being able to take local capacity restrictions into account. Second, due to the atomicity of payments, any failure in the path causes a failure of the complete payment. While there are suggested solutions for each of these problems --- namely splitting payments, local routing, and adding redundancy ---, there is no solution that solves both of them.

In this work, we propose JustForward: The payer adds redundancy to the payment by initially committing to sending a higher amount than the actual payment value $v$. Intermediaries decide on how to forward a received payment, potentially splitting it between multiple paths. If they cannot (or do not want to) forward the complete payment value, they may reduce the amount they forward. If paths for at least $v$ coins are found, the receiver and source jointly select the amounts of sub-payments that make up the full payment. Payment commitments are updated accordingly and fulfilled. In order to guarantee atomicity and correctness of the payment value, we use a modified Hashed Time Lock Contract (HTLC) for paying that requires both the payer and the payee to provide a secret pre-image. JustForward furthermore is the first local routing protocol to include fees: The source adds a maximal amount of fees they are willing to pay to the payment. Intermediaries take fees as they see fit, taking into consideration that subsequent nodes on the path will not forward the payment if there are insufficient fees left.

We prove that the proposed protocol achieves balance security, atomicity, bounded loss for the sender, and optionally unlinkability of split sub-payments of the same overall payments. Furthermore, our evaluation on both synthetic and real-world Lightning topologies shows JustForward outperforms existing algorithms in terms of the fraction of successful payments as long as the degree of redundancy is not too high. Concretely, for a moderate amount of redundancy, JustForward increases the success ratio of payments by about 10%.