Bitcoin Clique: Channel-Free Off-Chain Payments Using Two-Shot Adaptor Signatures

Abstract

Blockchains suffer from scalability limitations, both in terms of latency and throughput. Various approaches to alleviate this have been proposed, most prominent of which are payment and state channels, sidechains, commit-chains, rollups, and sharding. This work puts forth a novel commit-chain protocol, Bitcoin Clique. It is the first trustless commit-chain that is compatible with all major blockchains, including (an upcoming version of) Bitcoin.

Clique enables a pool of users to pay each other off-chain, i.e., without interacting with the blockchain, thus sidestepping its bottlenecks. A user can directly send its coins to any other user in the Clique: In contrast to payment channels, its funds are not tied to a specific counterparty, avoiding the need for multi-hop payments. An untrusted operator facilitates payments by verifiably recording them.

Furthermore, a novel technique of independent interest is used at the core of Bitcoin Clique. It builds on Adaptor Signatures and allows the extraction of the witness only after two signatures are published on the blockchain.

A Bitcoin Clique Healing

In its previously described form, Bitcoin Clique is vulnerable to a DoS attack: When the exit phase is initiated by any user, the entire Clique is torn down for everyone. We here propose an extension to the protocol, named healing, which allows active users to reinstate the Clique securely with minimal on-chain overhead.

At a high level, healing works by enabling a new way to spend tree txs which needs the active participation of all relevant users and $Op$. After some users exit, some tree tx outputs remain unspent. The users that want to stay in the Clique collaborate with each other and with $Op$ to create a single transaction that spends all remaining tree tx outputs using the new spending method and produces a suitable step tx output. The protocol is resilient to inactive users.

1.1 A.1 Healing Extension Details

In more detail, the solution is as follows: Consider an output of an arbitrary tree tx, which is spendable by the subset of users $\mathcal {T} \subset \mathcal {P}$. We add an alternative spending method, named healing, to the tree tx. Its script is $\bigwedge \limits _{P \in \mathcal {T}}P \wedge Op$. This modification is done to every tree tx of every epoch.

$s+1$ blocks after an exit phase is initiated, a user P that wishes to keep its coins in the Clique first initializes $\mathcal {C} \subset \mathcal {P}$ as the set of users that have not exited (i.e., the users of whom the out tx is not on-chain) and then repeats the following steps until either healing is complete (step 2) or the need for P to exit arises (discussed after the healing steps).

• 1. Generate and sign a new step tx that spends all currently unspent tree outputs using the healing spending method and has a single output with the coins and script of a step tx for users $\mathcal {C}$ (with the same b as the step tx that was exited from). See also Fig. 14 of the full version [47]. If the current block is within the epoch update period (Fig. 12 of the full version [47]) of the exited-from step tx, then produce the successor to the exited-from step tx instead (i.e., produce the step tx that would spend the exited-from step tx, two epochs later). Gossip signatures with other users and $Op$.

• 2. Wait for $t_{\textsf{reconcile}}$ blocks (a system-wide parameter, discussed in A.2). If all users in $\mathcal {C}$ and $Op$ sign the new step tx as well within this period, then publish it to the ledger. Healing is complete.

• 3. Else:

  • (a) Remove from $\mathcal {C}$ the users that have not provided the aforementioned signature.

  • (b) Publish to the ledger the minimum set of tree txs on the path from the root to P’s leaf so that all users that can spend the resulting tree output are in $\mathcal {C}$. (This action ostracizes inactive users on P’s path.)

  • (c) Wait for $s+1$ blocks (giving time to our and other branches to finalize on-chain).

  • (d) Remove from $\mathcal {C}$ all users that can spend an unspent tx tree output that can also be spent by a user in $\mathcal {P}\setminus \mathcal {C}$. (This action ostracizes users that did not ostracize inactive users on other paths by following step 3b. This is needed because the healing spending method needs the signature of all relevant users.)

The procedure needs to be repeated potentially many times because previously active users may become uncooperative in the process.

The need for P to exit arises if the new step tx has not been published by block $t_{\textsf{leave}}-s$. In that case, P exits by publishing its branch of the tx tree and out tx as usual. This scenario can happen if $Op$ becomes malicious and does not sign the new step tx, or if the other users maliciously classify P as inactive and do not include its tree output in the step tx. This, together with the fact that all relevant users (including P) need to sign for the healing spending method to be used and the fact that P only uses it to return to a normal step tx, guarantees that the healing extension safeguards balance security.

$Op$ follows the same procedure as the users, apart from step 3b. Since its signature is needed for all healing spending methods and it only uses it to return to a normal step tx, operator balance security is guaranteed.

It is possible for the protocol to be executed on both active step txs simultaneously — balance security and healing are maintained.

1.2 A.2 Discussion and Future Work

Note that $t_{\textsf{reconcile}}$ does not appear in any timelock, as it only dictates off-chain communication timeouts. It could therefore be alternatively expressed in terms of time. We here however express $t_{\textsf{reconcile}}$ in terms of blocks for homogeneity of notation. We recommend using the shortest $t_{\textsf{reconcile}}$ value that ensures each user has enough time to do a communication round-trip with every other user.

During healing, users might end up being too quick to assume another user is inactive and publish a tree tx that is not strictly needed. This incurs unneeded on-chain fees. A practical system would need to experiment with concrete parameters to minimize such events while promoting quick healing. Users are encouraged to be online and share as many signatures as possible as early and widely as possible to minimize such events, as well as being Bitcoin peers with each other in order to minimize discrepancies in their ledger views. To further mitigate this effect, it is possible to design a more elaborate synchronization protocol that allows users that were erroneously assumed inactive in step 3d to be re-included in the set of active users during the subsequent signature gossip step 1. We leave this as future work.

The above shows that this is a best-effort mechanism and does not benefit from uniquely attributable faults, which would in turn enable exclusion of malicious users from the healed Clique. There are specific cases in which it is possible to uniquely attribute faults, such as when a user publishes the root tx and no subsequent tree tx. We leave detecting and punishing uniquely attribute faults as future work.

Nevertheless, the healing mechanism can save a lot of on-chain transactions in many realistic scenarios of DoS attempts and always leads to reinstating and continuing the Clique with all honest, active users irrespective of the number of malicious users if $Op$ is honest and network delays are bounded.

Let us give us two example scenarios: In case a single user unilaterally exits and everyone else cooperates, then the on-chain footprint is $\log _2(N)$ transactions of the tree, 1 out tx, and 1 healing step tx. On the other hand, if at least one user of each leaf tx is malicious and publishes its entire branch of the tx tree, but not its out tx, then healing results in putting the entire tree tx on-chain and then recreating the exact same step tx output that was initially spent, for a total of 2N on-chain txs. The latter is the worst case scenario. We observe that even in this case, honest users can still successfully heal.

In a practical deployment, $Op$ can facilitate the protocol by being the primary point of contact for users and leveraging its (presumably) better network connection to enhance coordination, collect and distribute signatures, and signal which users are inactive. Still, users must not rely solely on $Op$ for message passing, lest they want to give it the ability to suppress an honest, active user.