Fail-safe Watchtowers and Short-lived Assertions for Payment Channels

Abstract

The recent development of payment channels and their extensions (e.g., state channels) provides a promising scalability solution for blockchains which allows untrusting parties to transact off-chain and resolve potential disputes via on-chain smart contracts. To protect participants who have no constant access to the blockchain, a watching service named as watchtower is proposed-a third-party entity obligated to monitor channel states (on behalf of the participants) and correct them on-chain if necessary. Unfortunately, currently proposed watchtower schemes suffer from multiple security and efficiency drawbacks. In this paper, we explore the design space behind watchtowers. We propose a novel watching service named as fail-safe watchtowers. In contrast to prior proposed watching services, our fail-safe watchtower does not watch on-chain smart contracts constantly. Instead, it only sends a single on-chain message periodically confirming or denying the final states of channels being closed. Our watchtowers can easily handle a large number of channels, are privacy-preserving, and fail-safe tolerating multiple attack vectors. Furthermore, we show that watchtowers (in general) may be an option economically unjustified for multiple payment scenarios and we introduce a simple, yet powerful concept of short-lived assertions which can mitigate misbehaving parties in these scenarios. CCS CONCEPTS • Security and privacy → Distributed systems security.

Decentralizing Watchtowers for Payment Channels using IPFS

“…4) Other Watchtower Approaches: Other approaches for watchtowers have been proposed that require changes to the underlying Bitcoin protocol [13], [14] or are based on Ethereum [15], [16] which offers a richer feature set for smart contracts compared to Bitcoin. Another line of research explored how to integrate watchtowers into the payment channel protocol [17]- [19].…”

“…16 bytes for the first half of the commitment transaction id, 450 bytes for the revocation transaction, 32 bytes for the reward key rk and 3 bytes for spaces and the newline result in 501 bytes per line. 501 bytes * 1.000.000 ≈ 501 megabytes5 16 bytes for the first half of the commitment transaction id, 42 bytes for the CID and 2 bytes for the space and the newline result in 60 bytes per line.…”

The Security Reference Architecture for Blockchains: Toward a Standardized Model for Studying Vulnerabilities, Threats, and Defenses

“…However, to avoid misbehavior in which a "stale" balance is settled on-chain, these systems require that the parties constantly monitor the blockchain state. Such an always-online assumption can be relaxed by employing watching services [195], [196], [197] (a.k.a., watchtowers), which, however, incur extra costs.…”