Daric: A Storage Efficient Payment Channel with Punishment Mechanism

Abstract

Lightning Network (LN), the most widely deployed payment channel for Bitcoin, requires channel parties to generate and store distinct revocation keys for all n payments of a channel to resolve fraudulent channel closures. To reduce the required storage in a payment channel, eltoo introduces a new signature type for Bitcoin to enable payment versioning. This allows a channel party to revoke all old payments by using a payment with a higher version number, reducing the storage complexity from $\mathcal {O}(n)$ to $\mathcal {O}(1)$. However, eltoo fails to achieve bounded closure, enabling a dishonest channel party to significantly delay the channel closure process. Eltoo also lacks a punishment mechanism, which may incentivize profit-driven channel parties to close a payment channel with an old state, to their own advantage.

This paper introduces Daric, a payment channel with unlimited lifetime for Bitcoin that achieves optimal storage and bounded closure. Moreover, Daric implements a punishment mechanism and simultaneously avoids the methods other schemes commonly use to enable punishment: 1) state duplication which leads to exponential increase in the number of transactions with the number of applications on top of each other or 2) dedicated design of adaptor signatures which introduces compatibility issues with BLS or most post-quantum resistant digital signatures. We also formalise Daric and prove its security in the Universal Composability model.

A Ideal Functionality

This section defines an ideal functionality $\mathcal {F}(T)$ with $T>\varDelta$ that achieves the desired properties stated in Sect. 5.2. To simplify the notations, we abbreviate $\mathcal {F}:=\mathcal {F}(T)$. The ideal functionality $\mathcal {F}$ stores a set $\varGamma$ of all the created channels and their corresponding funding transactions. The set $\varGamma$ can also be treated as a function s.t. $\varGamma (id)=(\gamma ,\texttt{TX})$ with $\gamma .\textsf{id}=id$ if $\gamma$ exists and $\varGamma (id)=\perp$ otherwise. Before presenting the ideal functionality $\mathcal {F}$ in details, we briefly introduce its different phases and explain the way $\mathcal {F}$ achieves the desired properties.

a) Create: In this phase, $\mathcal {F}$ receives messages $(\texttt{INTRO},\gamma ,tid_{P})$ and $(\texttt{CREATE},\gamma .\textsf{id})$ from both parties in rounds $\tau _0$ and $\tau _0+1$, respectively, where $tid_P$ specifies the funding source of the user P. Then, if the corresponding funding transaction appears on the ledger $\mathcal {L}$ within $2+\varDelta$ rounds, $\mathcal {F}$ sends the message $(\texttt{CREATED},\gamma .\textsf{id})$ to both parties and stores $\gamma$ and the funding transaction in $\varGamma (\gamma .\textsf{id})$. If the $\texttt{CREATE}$ message is not received from both parties but the funding transaction appears on $\mathcal {L}$ within $2+\varDelta$ rounds, $\mathcal {F}$ outputs $\texttt{Error}$. Since the message $\texttt{CREATED}$ might be sent to the parties only if they both have sent the message $\texttt{CREATE}$ to $\mathcal {F}$, the ideal functionality achieves “consensus on creation”.

b) Update: One of the parties, denoted by P, initiates this phase by sending the message $(\texttt{UPDATE},id,\mathbf {\theta },t_{stp})$ to $\mathcal {F}$, where id is the channel identifier, $\mathbf {\theta }$ is the new channel state and $t_{stp}$ is the number of rounds needed to prepare prerequisites of the channel update (e.g. preparing the needed HTLCs). Due to disagreeing with the new state or failure in preparing its prerequisites, party Q can stop it by not sending the message $(\mathtt {UPDATE-OK},id)$ in step 2. Abort by P or Q in next steps causes the procedure $\texttt{ForceClose}(id)$ to be executed. The property “optimistic update” is satisfied because if both parties act honestly, the channel can be updated without any blockchain interaction. Furthermore, if P or Q disagree to update the channel, they can stop sending the $\texttt{UPDATE}$ or $\mathtt {UPDATE-OK}$ messages, respectively. This stops the channel update process without changing the latest channel state. Also, in cases where either P or Q stop cooperating, the procedure $\texttt{ForceClose}(id)$ is executed. This procedure takes at most $\varDelta$ rounds to complete. This also guarantees “consensus on update”.

c) Close: If $\mathcal {F}$ receives the message $(\texttt{CLOSE},id)$ from both parties, a transaction $\texttt{TX}$ is expected to appear on $\mathcal {L}$ within $\varDelta +1$ rounds. This transaction spends the output of the funding transaction and its outputs equal the latest channel state $\gamma .\textsf{st}$. If the $\texttt{CLOSE}$ message is received only from one of the parties, $\mathcal {F}$ executes the procedure $\texttt{ForceClose}(id)$. In both cases, output of the funding transaction must be spent within $\varDelta +1$ rounds. Otherwise, $\mathcal {F}$ outputs $\texttt{Error}$.

d) Punish: If a transaction $\texttt{TX}$ spends the funding transaction’s output of a channel $\gamma$, one of the following events is expected to occur: 1) another transaction appears on $\mathcal {L}$ within $\varDelta$ rounds where this transaction spends output of $\texttt{TX}$ and sends $\gamma .\textsf{cash}$ coins to the honest party P; or 2) another transaction whose outputs correspond to the channel state $\gamma .\textsf{st}$ or $\gamma .\mathsf {st'}$ appears on $\mathcal {L}$ within $T+\varDelta$ rounds. Otherwise, $\mathcal {F}$ outputs $\texttt{Error}$. According to its definition, “bounded closure with punish” is achieved, if $\mathcal {F}$ returns no $\texttt{Error}$ in the close and punish phases.

We describe the ideal functionality below. Normally, once $\mathcal {F}$ receives a message, it performs several validations on the message. But to simplify the description, we assume that messages are well-formed. Data exchange between $\mathcal {F}$ and other parties is represented by directed arrows. If $\mathcal {F}$ sends the message m to party P in round $\tau _0$, we denote it with . Similarly, if $\mathcal {F}$ is supposed to receive the message m from party P in round $\tau _0$, we denote it with .