Contingent Payments on a Public Ledger: Models and Reductions for Automated Verification

Abstract

We study protocols that rely on a public ledger infrastructure, concentrating on protocols for zero-knowledge contingent payment, whose security properties combine diverse notions of fairness and privacy. We argue that rigorous models are required for capturing the ledger semantics, the protocol-ledger interaction, the cryptographic primitives and, ultimately, the security properties one would like to achieve. Our focus is on a particular level of abstraction, where network messages are represented by a term algebra, protocol execution by state transition systems (e.g. multiset rewrite rules) and where the properties of interest can be analyzed with automated verification tools. We propose models for: (1) the rules guiding the ledger execution, taking the coin functionality of public ledgers such as Bitcoin as an example; (2) the security properties expected from ledger-based zero-knowledge contingent payment protocols; (3) two different security protocols that aim at achieving these properties relying on different ledger infrastructures; (4) reductions that allow simpler term algebras for homomorphic cryptographic schemes. Altogether, these models allow us to derive a first automated verification for ledger-based zero-knowledge contingent payment using the Tamarin prover. Furthermore, our models help in clarifying certain underlying assumptions, security and efficiency tradeoffs that should be taken into account when deploying protocols on the blockchain.

MAD-HTLC: Because HTLC is Crazy-Cheap to Attack

“…If Alice does not publish her transaction before T 2 elapses, then the swap is canceled. c) Zero-knowledge contingent payments: These [16], [17], [18], [19], [20] are transactions allowing Bob to purchase a secret from Alice such that he learns the secret if and only if the payment is performed.…”

“…A variety of more elaborate smartcontract designs rely on HTLC as a building block ( §II). These include high-frequency payment channels [4], [5], [6], [7], [8], [9], [10], atomic swaps [11], [12], [13], [14], [15], contingent payments [16], [17], [18], [19], [20], and cryptocurrency vaults [21], [22], [23], [24]. We identify the specification required by the variety of contracts using HTLC and call it HTLC-Spec.…”

Contingent payments from two-party signing and verification for abelian groups

“…Security definitions for ZKCP and security proofs for this protocol have been proposed both in the symbolic [18] and in the computational model [60]. However, there are still several drawbacks in practice.…”

“…We improve the ZKCP symbolic security definition from [18], making it amenable to automation, since their property cannot be fully verified with tools like Tamarin. We also make it more general, as the receiver property from [18] needs to be adapted according to the structure of the protocol. Finally, we also make it stronger.…”

“…Finally, we also make it stronger. Indeed, the receiver property from [18] only ensures that the witness is deducible by the receiver, i.e. there exists a sequence of computation steps that allows to deduce the witness.…”