CoinPool: efficient off-chain payment pools for Bitcoin
Gleb Naumenko

Antoine Riard

gleb@thelab31.xyz

antoine@thelab31.xyz

ABSTRACT
CoinPool is a new multi-party construction to improve Bitcoin onboarding and transactional scaling by orders of magnitude.
CoinPool allows many users to share a UTXO and makeinstant off-chain transfers inside the UTXO while allowing
withdrawals at any time without permission from other users.
In-pool accounts can be used for advanced protocols (e.g.,
payment channels). Connecting them to other CoinPool instances, or even to the Lightning Network, makes in-poolfunds highly liquid.
CoinPool construction relies on 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃 ,𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 and 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵
changes to Bitcoin. It also assumes a high degree of interactivity between pool participants.

1

INTRODUCTION

While Bitcoin has established itself as a store-of-value, it is
yet to be explored whether it can enable high transaction
throughput without sacrificing security. Among many proposals [7, 9, 19] to achieve this goal, most attention was drawn
to the Lightning Network [17].
Once LN matures and expands, its scalability and usability
may face the following challenges:∙ while technically two-party payment channels can exist
off-chain forever, in practice they suffer from liquidity
depletion bounding their lifetime∙ two-party payment channels occupy significant block
space per user when they get opened/closed, setting abound on the number of LN users concurrently∙ multi-hop trust-minimized routing may cause evenmore channel closings (in-flight HTLCs leading to onchain claims)
Based on the lessons learned from the design and operationof the LN and other protocols, we propose CoinPool: a new
scalability construction based on sharing UTXO ownership.
It provides the following features:∙ users can transfer their funds off-chain inside the pool
∙ every user can unilaterally exit a pool at any time
without permission from other users∙ in-pool accounts could be used for advanced contracts(e.g., payment channels)∙ in-pool accounts could be used to transact with usersof the LN or another CoinPool instance2

BACKGROUND

Bitcoin is a peer-to-peer electronic cash system, in which alltransactions are verified by users running node software. To
let everyone participate in the most secure way and withminimized trust, Bitcoin limits transaction throughput tocap system requirements.

2.1

Bitcoin Transactions

Bitcoin addresses and the corresponding amounts define thestate of the funds. Every address refers to a challenge to besatisfied to use a corresponding amount. Satisfying the mostbasic challenge requires a digital signature corresponding toa given public key.
Bitcoin Script is a language for expressing challenges thatlock the coins. Bitcoin Script was designed to ensure low
verification cost and enable running a Bitcoin node on lowtier hardware.
The main building block in Bitcoin Script is an opcode. For
example, OP CHECKSIG is used for signature verification.
Other opcodes allow locking funds for a certain time, or until
a preimage is revealed for a given hash.
Every transaction consists of the following components:∙ inputs referring to the coins being spent∙ scripts containing the rules locking the coins (scriptPubKey)∙ signatures satisfying the scripts (scriptSig)∙ outputs referring to the new rules locking those coins
A script and a corresponding solution (e.g., a digital signature) together are called a witness, as they allow to checktransaction validity but not to determine transaction effects.
When Alice sends her coins to Bob, she crafts a transaction
proving her ownership of a certain Unspent Transaction
Output (UTXO). Then Alice broadcasts this transactionin the Bitcoin network to get it recorded in the Bitcoin
blockchain.
2.1.1 Sighashes,
SIGHASH GROUP
andSIGHASH ANYPREVOUT. A sighash flag is part of asignature indicating which part of the transaction body issigned. For example, a signature could cover all inputs andoutputs (𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝐿𝐿) or all input and one output(𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝑂𝑁 𝐸). These different modes of operation
become useful in multi-key settings.
The following sighash flags were proposed to extend Bitcoin
validation rules:∙ 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃 to enable bundling inputs withany number of outputs∙ 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 to avoid committing to
outputs being spent
2.1.2 Covenants. Bitcoin Script opcodes constraining spending transactions in terms of scriptPubKeys of their outputs
are called covenants [10]. For example, Alice can send funds
to Bob, which Bob can only spend to a specific address. Aliceenforces this by asking Bob to construct his scriptPubKey ina certain way; and sends to that address.
Covenants are useful for protocols in which several users
share a single UTXO. With this feature, users can be surethat they will receive a fraction of coins when the UTXO isspent.
2.1.3 Taproot. Taproot is a UTXO format, which could bespent by satisfying one of the alternative conditions, represented as a Merkle tree. Spending a Taproot UTXO involves
revealing a scriptPubKey, a corresponding Merkle branch,
and a scriptSig.
In a multi-party setting, protocol participants may choose
to tweak the Merkle root of a tree with an aggregation of
their public keys, to avoid revealing the tree if they agree on
payment details at the spending time. This aggregation iscalled an internal pubkey.

2.2

3

2.2.1 Routing and the Lightning Network. Payment channels
can be connected in a graph to enable payments between
users not connected via a direct channel. The process of
forwarding payments is called routing.
Lightning Network is an instance of a Payment Channel
Network based on two-party channels. It is the most widelyused off-chain protocol, with thousands of bitcoins locked in
the network.

Off-chain update mechanisms

An update mechanism is what invalidates a state of a payment
channel (or similar construction) while transitioning to a newstate without touching the blockchain.
Currently, payment channels rely on LN-Penalty [17]: apayer discloses a secret revoking a previous set of pre-signed
transactions. If a revoked transaction is published, the payee
can use the disclosed secret to confiscate the payer’s balance.
LN-Penalty does not work for N-channel users because 1)
it requires storing all historical pre-signed transactions andrevocation secrets, which does not scale well with the number

OFF-CHAIN SCALING

When it comes to scaling Bitcoin with off-chain protocols,
two factors matter: onboarding and transactional scaling.
Let’s now analyze the LN in light of these two metrics.

3.1

Onboarding scaling

This metric defines how many users can co-exist off-chain,considering throughput limits at the Bitcoin base layer.
Let’s assume the following properties of the LN:∙ channel lifetime is 𝑇 𝑑𝑎𝑦𝑠
∙ every time a user closes a channel, they open a new
one in the same transaction∙ every block can contain at most 3000 transactions

Payment channels

Off-chain solutions increase Bitcoin throughput at the costof additional assumptions.
Payment channel protocols allow making multiple payments within a collateral capacity without recording a transaction in the blockchain (except for channel opening and closing transactions). Instead, channel counterparties pre-sign
Bitcoin transactions and keep them locally. These transactions appear in the blockchain to enforce the latest channel
state (balances) only when channels get closed.
This optimization comes with a new threat model. Users
have to monitor the chain (and act in case of misbehavior)so that their counterparty cannot quietly settle an outdated
state. This requirement contrasts with regular Bitcoin payments, in which users monitor the chain only at payment
receiving time. This new threat model comes with an extended set of assumptions [1, 8, 18].

2.3

of users; 2) distributing confiscated balance across N users
remains an open game-theoretic question.
Eltoo is an alternative update mechanism [3] that overcomes these issues by introducing state ordering at the Bitcoin Script level, once 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 is deployed.

Then, 𝑇 𝑑𝑎𝑦𝑠 * 144𝑏𝑙𝑜𝑐𝑘𝑠/𝑑𝑎𝑦 * 3000𝑡𝑥𝑠/𝑏𝑙𝑜𝑐𝑘 is the upperbound for a number of co-existing channels. If an averagechannel lifetime is 30 days, at most 13,000,000 channels could
exist simultaneously in a secure way.

3.2

Transactional scaling

This metric defines how many transfers can be performed offchain per on-chain transaction, considering the propertiesof the off-chain system.
The off-chain/on-chain ratio in the LN is limited becauseof the liquidity issues:∙ Routing limits the capabilities to pay and receive payments in the network, forcing users to go on-chain.
∙ Channel owners have different goals while maintaining
a payment channel 1 .

4

COINPOOL:SCALABILITY/SECURITY MODEL

CoinPool is a trust-minimized multi-user (𝑁 > 2) off-chain
protocol that provides high onboarding and transactional
scaling at the cost of high interactivity.
Balances in the pool are organized in a Taproot tree, whereleaves ensure every user can spend their balance immediately
without permission from other users. A user cannot losebalance or be forced to leave the pool.
To make sure a withdrawing user preserves the state of
the remaining CoinPool, unilateral withdrawals must be restricted, so that a user cannot withdraw more than theirbalance, and the rest of the tree should remain unmodified(see Fig. 1).
Off-chain transfers work by spending a CoinPool output
into new CoinPool output of arbitrary state via replacing
1

For example, if one channel counterparty raises routing fees over thechannel, it may become prohibitively expensive for another counterparty to rebalance the channel.

tUsed for returning to
off-chain operations
after a unilateral
withdrawal

Internal aggregate
keyt

CoinPool
outputUsed for Eltoo'ed
cooperative pool
updates

Aggregate key

Cooperate to replacepre-signed TXs without
going on-chain

Unilateral withdraw leaves.
A pre-signed component
from the rest of the pool
restricts the spending.

Merkleroot

Alice

Other pool participants must
make sure this includes
OP_MERKLESUB and
OP_CHECKSIG over theiraggregate key

Bob

Carol

Carol withdraws
on-chain unilaterally

CoinPoolstate N

CoinPoolstate N+1

CoinPoolstate N+2

Alice: 1 BTC

Alice: 1 BTC

Alice: 1 BTC

Bob: 1 BTC

Bob: 0.5 BTC

Bob: 0.5 BTC

Carol: 1 BTC

Carol: 1.5 BTC

Figure 2: CoinPool: users can transfer funds within
a single UTXO and withdraw at any time.
Figure 1: CoinPool is organized as a tree, in whichleaves correspond to user balances and enable unilateral withdrawals. Two extra spending paths areused for cooperative pool operations.

pre-signed transactions. This transition must be authorizedby all participants’ aggregate public key and with the use of
Eltoo.
CoinPool balances can be locked with arbitrary scripts,
which allows them to be used as payment channels. This
allows 1) connecting CoinPool instances to each other andto the LN; 2) not to ask permission for balance-level statechanges from the rest of the pool, which improves scalability 2
and privacy. Other pool-level actions (for example, transfers
between balances) do not affect the operation of these in-poolpayment channels.

4.1

Enabling any-order exits in a scalable
way with OP MERKLESUB,
SIGHASH ANYPREVOUT and
SIGHASH GROUP

The ability to exit a pool at any time without permission isa fundamental CoinPool feature.
Two primitives are used to restrict a withdrawing participant from violating rules: 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃 to restrict
the balance, and 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵 to maintain the tree,
which we present shortly (but also uses 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃
and 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 ) 3 .
Now, we present 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵.
4.1.1 Enforcing tree transitions with OP MERKLESUB. Every pool withdrawal results in two new UTXOs: onefor the exiting user, and one for the rest of the pool.
𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵 is a new opcode enforcing that the
new CoinPool UTXO is equal to the UTXO this transactionis spending, but:
2

In the next section, we will show that by default, such actions requireauthorization from all pool participants
3
These restrictions could be also achieved by pre-signing all possible
sequences of state transitions (producing, storing and exchanging allthese signatures), which scales poorly (factorial) with the number ofparticipants. For balances specifically, another potential solution isto enforce all balances to be equal, which would significantly reduce
CoinPool usability.

∙ user’s leaf is subtracted from the Merkle tree
∙ user’s pubkey is subtracted from the internal pubkey
At the transaction verification level, these rules require
Merkle tree subtraction and elliptic curve point addition.
This scheme also relies on:∙ 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 allowing signatures tonot commit to a particular input∙ 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃 allowing signatures to not commit to a particular output
All these features combined ensure any-order pool exits
without authorizing every possible sequence of exits via afactorial number of signatures.

4.2

Enabling leaf-level payment channels
with SIGHASH ANYPREVOUT

Using CoinPool leaves as two-party payment channels or
similar protocols largely increases the scalability of CoinPool.
This feature requires 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐴𝑁 𝑌 𝑃 𝑅𝐸𝑉 𝑂𝑈 𝑇 , because otherwise transactions enforcing leaf-level payment
channels would have to commit to a particular CoinPool
state hash, which means every state change of the pool would
invalidate these payment channels.

5

COINPOOL OPERATIONSCoinPool instance state is defined by a set of public keys
and the associated balances, which are debited and credited
during pool operation.
This state is maintained by an on-chain UTXO and a setof pre-signed transactions. Pre-signed transactions are theonly objects aware of user balances: they restrict users fromexceeding balances while withdrawing.
Off-chain transfers between pool accounts require replacing
pre-signed transactions with new ones. All pool participants
have to approve these transitions (see Fig. 2). If an update
reduces the balance of a user unexpectedly, this user should
refuse to authorize the update.
If an outdated transaction is published on-chain, participants should challenge it to make sure their funds remain
safe. This action requires all pool participants to store thepool state locally.

tt
Unilateral
withdrawals

Withdraw TX
Update #0
TX

Withdraw TX
At Setup, only thisTX goes on-chain

Update #0
TX

CoinPool
outputWithdraw TX
Withdraw TX

Withdraw TX
Setup TX

Withdraw TX
Setup TX

CoinPool
output

PreCoinPool
output

PreCoinPool
outputEltoo is used toreplace previous TX
Update #1
TX

CoinPool
outputScripts are rotated toinvalidate previous TXs
Withdraw TX
Withdraw TX
Withdraw TX

Figure 3: Pool Setup: Update #0 TX and Withdraw
TXs are signed, then Setup TX is signed and submitted on-chain.

The CoinPool UTXO usually gets re-spent on-chain when
one of the participants leaves the pool. This action does not
require permission from the rest of the pool.
The distribution of the balances, and even the existenceof the pool, is hidden from external observers.

5.1

Pool Setup

Bitcoin users initiate a CoinPool instance by crafting a Setup
transaction, an Update transaction with an initial state;
and one Withdraw transaction spending an Update output for every user (see Fig. 3).
To make sure funds don’t get frozen, transactions are
signed in reverse topological order.
Inputs of a Setup transaction correspond to users’ contributions, and the only output funds the CoinPool state.
This output can be spent by all participants together unconditionally. This output is called pre-CoinPool : it does notallow unilateral withdrawals yet (an already signed Update
transaction must be published first).
We will now explain the construction of Update and Withdraw transactions.

5.2

Pool Update (off-chain)

Initiating a transfer to another pool balance or changes tothe lock conditions (key rotation, adding a timelock) requires
proposing an Update transaction spending pre-CoinPool
UTXO into new off-chain output. If another update alreadyexisted on top of the pre-CoinPool UTXO, it should be
replaced via Eltoo.
After verifying the correctness of the transition, otherparticipants authorize this update by 1) generating/signinga new set of Withdraw transactions; 2) signing the proposed
Update transaction (see Fig. 4).
The output of the Update transaction is a CoinPool Taproot output with the following spending paths:∙ Key path remains the same as in the UTXO being spentand requires authorization from all pool participants
cooperatively∙ Script path represents a tree ensuring: 1) every user
has a leaf allowing them to withdraw at any time
without permission, although in a restricted way (seeFigure 4: CoinPool Update: Users cooperate to produce a new Update transaction enforcing pool statetransition. Withdraw transactions should be invalidated by rotating scripts.

next Section); 2) one Eltoo-enabled leaf based on theaggregate public key enables off-chain. transitions 4
Pool participants must force each other to rotate their withdraw scripts, to invalidate existing Withdraw pre-signatures,
which otherwise may be used to double-spend honest users.
Once a new Update transaction and a new set of Withdraw
transactions are generated and signed, this update is finalized.
No recording in the blockchain is required.

5.3

Pool Withdrawal

Every pool participant can withdraw their balance fromthe pool at any time. Spending a Withdraw transaction
always involves using a private component by the leaf owner
and a pre-signed component signed by other participants.
First, a withdrawing participant submits the latest Update
transaction.
Then, the contestation delay takes place: a withdrawinguser should wait for a certain number of blocks before submitting a Withdraw transaction. This delay lets other users react
if the submitted Update transaction was not the latest. Thisdelay is enforced in the pre-signed component of Withdraw
transactions.
Once the delay is over, a Withdraw transaction spends the
CoinPool UTXO into two outputs: one for the withdrawal(see Fig. 5), and one for the remaining pool. In addition tosatisfying the user’s scriptPubKey content of the leaf, thetransaction must satisfy the following:(1) Second output is a Taproot output with the same tree
from the UTXO being spent, but the withdrawing user
is excluded from both key and script paths.
(2) A point and a leaf removed from the tree should correspond to the withdrawing user’s point and leaf.
(3) First output amount should correspond to the balance
assigned to the leaf.
(4) Second output amount should equal the previous poolamount without the second output amount.
4

This can’t be done via key path. Key path in the CoinPool output
from an Update transaction is not supposed to be spent at all, it is
only used for 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵.

t
PreCoinPool
outputContestation delay tolet other users react if
Update is outdated
Update #1
TX

CoinPool
outputRules over these outputs
are enforced by
OP_MERKLESUB and
SIGHASH_GROUP

Withdraw TXtCarol's Withdraw
pre-sigs remain
valid

CoinPool
output

PreCoinPool
outputWithdraw TX

Withdraw TX
Withdraw TX

Setup TX equivalent.
Generate a new Update TX andreplace Withdraw TXs.
Once confirmed on-chain, off-chain
operations can continue.

Update #1
TX

Bob

CoinPool
outputCoinPool
outputWithdraw TX

Figure 5: CoinPool Withdraw: Bob leaves the poolby using his private key and a pre-signed Withdraw
component from other participants. Then, Carol considers leaving with an existing pre-signed transaction.

(1) and (2) are enforced via 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵, whichmust be satisfied to spend the UTXO. Pool participants force
each other to always include 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵 in theirleaves.
(3) and (4) are enforced via 𝑆𝐼𝐺𝐻𝐴𝑆𝐻 𝐺𝑅𝑂𝑈 𝑃 flag
applied to the pre-signed component of the Withdraw transaction. Pool participants force each other to always include
𝑂𝑃 𝐶𝐻𝐸𝐶𝐾𝑆𝐼𝐺 over the aggregate key in their leaves andpre-sign these authorizations only with 𝑆𝐼𝐺𝐻𝐴𝑆𝐻𝐺 𝑅𝑂𝑈 𝑃 .
Users can withdraw from the pool one after each other.
In that case, no Update transaction will be recorded in theblockchain, but the second user would still have to wait during
the contestation delay after the first user 5 .

5.4

Pool Snapshot

Once a user withdraws from the pool, the remaining participants can either continue withdrawing non-cooperatively or
return to off-chain pool operations. For the latter, a Snapshot transaction must be confirmed on-chain. It ensuresthat outdated Withdraw pre-signed components are invalidated.
A Snapshot transaction takes one input from the key pathof the UTXO produced by the last Withdraw transaction
and spends it into one output, identical to the Setup output.
Similarly to Setup, participants should produce all required
Withdraw and Update transactions spending a Snapshot
output, before authorizing the Snapshot transaction.

5.5

Expanding the pool

To add a new user to the CoinPool instance, current participants spend the pool UTXO into new UTXO which includes
the new user (both in key path and script path), via an onchain transaction 6 . Similarly to Setup, all required Withdraw
and Update transactions should be generated.
5

It doesn’t provide additional security against the second withdrawal,
but it significantly simplifies the protocol design.
6
This transaction must be recorded on-chain, because otherwise newuser can’t be secure.

Snapshot TX

Withdraw TX
Bob

PreCoinPool
outputFigure 6: Coinpool Snapshot: once Bob withdrawn,a Snapshot transaction should be produced and confirmed on-chain in the same way as Setup. Then,
off-chain operations can proceed.

This action could use a cooperative Update transaction ora Snapshot transaction. A transaction could be expanded toinclude a contribution from the new user.

5.6

Optimizations

Going on-chain usually happens at unilateral Withdraw, or
while onboarding new users. These actions can be aggregatedwith each other or with other updates. One transaction can
include Alice leaving the pool, adding Bob to the pool, andtransferring funds from Carol to Dave.
Cooperative on-chain action is always cheaper in fees thanunilateral Withdraw, because transaction witness does notcontain Merkle path, and thus, is smaller and cheaper. For
off-chain, it just avoids producing a separate signature for atransfer.

6

UPLIFTING OFF-CHAIN
PROTOCOLS

CoinPool leaves could be used for advanced protocols (payment channels, Discreet Log Contracts [6], CoinSwaps [12]).
This is one of the key scalability improvements CoinPool
provides, which we call uplifting. Those protocols can operate
inside the pool without affecting the entire pool state (seeFig. 7).
An uplifted protocol instance is secure for all participants
only if all of them are involved in authorizing pool-wide actions: signing cooperative updates and pre-signing unilateral
withdrawals. Otherwise, a leaf can be modified without theuser’s consent.
Activity within an uplifted protocol instance (at a leaflevel) remains unknown to non-involved pool participants.
An uplifted protocol instance adheres to the same threat
model, as the non-uplifted version. A user has to:∙ monitor the blockchain to ensure no outdated state is
submitted [1]∙ make sure their reaction transactions could be timely
included in the blockchain [8, 18]
Additionally, pool timelocks (in Withdraw transactions)should be accounted for while picking timelocks for uplifted
protocol instances.

t
CoinPoolstate N

Alice: 1 BTC

Bob: 1 BTC
Carol-Dave:
1 BTC – 1 BTC

CoinPoolstate N

Global pool update is
unnecessary for statechanges in uplifted
protocolsfrom their first output (the remaining pool) as a condition
locking the second output (timelocked UTXO of a withdrawing participant), so that withdrawing users are excluded fromfurther contesting.

Alice: 1 BTC

7.3

Bob: 0.5 BTC

CoinPool updates require the participation of all pool participants. This sets an upper bound on the number of poolusers. The main bottlenecks are:Carol-Dave:
1.5 BTC – 0.5 BTC

Figure 7: Uplifting: a leaf-level payment channel canbe updated without affecting the rest of the pool.
Leaf-level payment channels may be used to route payments to the Lightning Network, or another CoinPool instance. To achieve this, one of the payment channel participants must have another payment channel in the second
system. This user would take the risks corresponding to crosssystem transfers, similarly to how routing nodes in the LN
take the risk for forwarding payments through their channels.
These payments have to be authorized only by leaf participants and remain unknown to the rest of the pool.

7 DISCUSSION
7.1 Economic soundness of multi-party
Eltoo
Eltoo assumes publishing a reaction transaction in case acounterparty confirmed an outdated transaction on-chain.
In a two-party setting, there is always an attacker and a
victim. In N-party protocols, there could be 𝑀 < 𝑁 victims.
It is unclear how victims coordinate the reaction, especiallyin terms of reaction transaction fees.
A protocol instance (e.g., CoinPool) may have an extra
leaf (or a standalone UTXO) with contributions from all pool
participants for this reason. Additionally, it can encouragehonest pool participants to be first at reacting by offering a
reward paid from this additional collateral.

∙ online: downtime of a single participant halts pool
updates∙ DoS-resistance: malicious participants proposing an
excessive number of updates; or denying to authorize
any updates∙ resources: latency and bandwidth/space required tocoordinate updates
Interactivity requirement also makes cold storage security
approach impossible for the keys authorizing updates.
To overcome these issues, we suggest several solutions:∙ applying reputation systems to select pool participantsfor DoS-resistance∙ replicated key hosting for better availability∙ kicking-out at the pool level: forcing a user to withdraw
after inactivity∙ in-pool fragmentation: updates in one branch withoutauthorization from another branches

7.4

Off-chain Cancellation of Withdraw
Transactions

Once a unilateral withdrawal was confirmed on-chain, continuing pool off-chain operations requires confirming a Snapshot
transaction, which results in extra on-chain footprint andcoordination.
A Snapshot transaction invalidates Withdraw transactions,because otherwise, if Alice withdraws right after Bob, Bob remains in the Eltoo leaf of Alice’s remaining pool output. The
remaining pool participants must not rely on Bob contesting
further updates.
Alternatively, this can be achieved by extending Bitcoin
Script rules to function across outputs. More specifically,
pool participants should be able to force (via a pre-signed
component) Withdraw transactions to use an internal pubkey

Withdraw witness size

Unilateral Withdraw transactions have large witness sizes
because they require revealing a Merkle branch containing
the withdrawing user’s leaf. Witness size in this case grows
logarithmically with the pool size.
This results in the inefficient use of Bitcoin throughput,and high fees for the withdrawing user.
We suggest the following optimizations:(1) Sharing leaves across several users via leaf-level conditions enabled by Bitcoin Script(2) A more efficient accumulator for inclusion proving [5].

7.5
7.2

Interactivity requirement

Dynamic Membership

CoinPool does not allow onboarding new users’ without an
on-chain transaction. This results in reduced scalability andusability of CoinPool.
Onboarding new users off-chain securely is hard, because
existing pool participants can cooperate to trick a new user
into believing new user’s funds are safe, and then doublespending via free-to-produce state fork.
We leave exploring this problem for future research.

7.6

Confidentiality enhancements

Even though CoinPool hides most of the activity from theoutsider, an in-pool observer can track all in-pool activities
unless they happen at the leaf level.
Anonymity can be increased by setting a lower bound on
in-pool balance and a timelock to prevent a spy from leaving

the pool immediately after entering, or via periodic in-pool
mixing.

Commodity trade is a widespread business activity withlonger timespans and across multiple jurisdictions. For these
deals, it is often useful to take many different events into
consideration and act accordingly.
CoinPool can be used to facilitate these advanced contracts
if every possible event corresponds to a pre-signed transaction
enforcing pool state transition.

factories, CoinPool remains operational after one participant
withdraws from the UTXO.
Joinpool [13] is a more generic UTXO sharing protocol,
which, unlike Channel factories, remains operational after auser withdraws. CoinPool extends this by offering off-chain
operations and protocol uplifting.
Both Channel factories and Joinpool protocols offer mixing
coins against an external observer, so does CoinPool.
The pooling idea was further advanced by representing
accounts in a Radix tree [21] for witness size reduction. Compared to this construction, CoinPool requires generation moretransactions and interactive setup, while offering a smaller
on-chain footprint and allowing unilateral withdrawals.
This Radix tree was prototyped on pre-signed transactions
without modifications to Bitcoin Script, while 𝑂𝑃 𝐶𝑇 𝑉 [20]was proposed to reduce construction complexity and risks
associated with pre-signed transactions.
𝑂𝑃 𝑇 𝐴𝑃 𝑅𝑂𝑂𝑇 𝐿𝐸𝐴𝐹 𝑈 𝑃 𝐷𝐴𝑇 𝐸 𝑉 𝐸𝑅𝐼𝐹 𝑌 [24] is a
Bitcoin Script extension allowing accumulator-based operations, similarly to 𝑂𝑃 𝑀 𝐸𝑅𝐾𝐿𝐸𝑆𝑈 𝐵. 𝑂𝑃 𝐶𝐴𝑇 [15] and𝑂𝑃 𝐶𝑆𝐹 𝑆 [16] are two other general-purpose covenant proposals to Bitcoin Script. These proposals may be used todesign pool protocols, although this direction was not thoroughly explored.

8.3

10

8 COINPOOL APPLICATIONS
8.1 Trading Pools
CoinPool can facilitate trading or liquidity management (forexample, between a broker firm and its clients) more efficiently than the LN or other systems, due to better confidentiality and funds velocity.
Pool policies could be optimized for trading, and include
market makers, trade ordering rules, or alternative thresholdconditions. For example, a broker could authorize a statetransition if 50% of participants confirm.

8.2

Commodity Contracts

Smart Corporation

A CoinPool instance can represent a corporation, with stakeholders having different balances and voting rights to implement corporate governance and distribute dividends. A
special balance could be used as a corporate account andcontrolled by the majority of the participants.
This idea gets more powerful once combined with otheradvanced protocols (e.g., Chaumian banks [2] or vaults [14,
23]).

9

RELATED WORKFirst multi-party (𝑁 > 2) protocols for Bitcoin were mixers
enhancing privacy by obfuscating coin ownership across manyusers [11, 12]. Similarly to CoinPool, they provide confidentiality against an outsider, but not against an in-protocol
spy. Although confidentiality boost is a secondary feature for
CoinPool.
Sidechains [7, 22] scale Bitcoin by locking Bitcoins controlled by an external consensus (e.g., a federation) to authorize state transitions. CoinPool is more trust-minimized thansidechains, but, unlike sidechains, it is limited by Bitcoin
Script for off-chain activities. Sidechains could use CoinPools
for locking and governing locked Bitcoins.
The Lightning Network [17] aims to increase transaction
throughput by moving most of the activity off the chain
via two-party payment channels. CoinPool builds on similar
scalability ideas while providing better funds velocity at a
cost of higher interactivity.
Channel factories [4] enhance the LN by batching openings
and closings of many channels into one transaction. CoinPool
also builds on the idea of UTXO sharing, but, unlike Channel

CONCLUSIONSLightning Network scales Bitcoin payments via two-party
payment channels and routing, although it may be boundedin terms of scaling and usability by its design.
We propose CoinPool, a covenant-based payment pool construction, which takes the idea of sharing UTXO ownershipto the next level. In CoinPool, Bitcoin users lock funds inmany accounts within a single UTXO to instantly transact
across the pool without much on-chain footprint; or use theiraccounts inside the pool for advanced protocols (e.g., payment channels), possibly even connected to other CoinPoolsor the LN. CoinPool users can withdraw their funds from thepool at any time.
CoinPool introduces an alternative set of trade-offs: users
get increased funds velocity and use Bitcoin throughput more
efficiently, at the cost of high interactivity required by pool
participants. CoinPool requires modifications to the Bitcoin
protocol.

REFERENCES[1] Gleb Naumenko Antoine Riard. Time-dilation attacks on thelightning network, https://arxiv.org/pdf/2006.01418.pdf, 2020.
[2] David Chaum. Blind signatures for untraceable payments. In
David Chaum, Ronald L. Rivest, and Alan T. Sherman, editors, Advances in Cryptology, pages 199–203, Boston, MA, 1983.
Springer US.
[3] Rusty Russell Christian Decker and Olaoluwa Osuntokun.
eltoo: A simple layer2 protocol for bitcoin,https://blockstream.com/eltoo.pdf, 2018.
[4] Christian Decker Conrad Burchert and Roger Wattenhofer.
Scalable funding of bitcoin micropayment channel networks, https://nakamotoinstitute.org/static/docs/scalablefunding-of-bitcoin-micropayment-channel-networks.pdf, 2018.
[5] Ben Fisch Dan Boneh, Benedikt Bunz. Batching techniques foraccumulators with applications to iops and stateless blockchains,https://eprint.iacr.org/2018/1188.pdf, 2018.

[16] Russell[6] Thaddeus
Dryja.
Discreetlog
contracts,
O’Connor.
Catandschnorrtricksi,
https://adiabat.github.io/dlc.pdf, 2017.
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr[7] Adam Back et al. Enabling blockchain innovations with pegged
tricks-i.html, 2021.
sidechains, https://www.blockstream.com/sidechains.pdf, 2014.
[17] Joseph Poon and Thaddeus Dryja.
The bitcoin lightning
network:
Scalable
off-chaininstant
payments,[8] Aviv Zohar Jona Harris. Flood & loot: A systemic attack on thelightning network, https://arxiv.org/pdf/2006.08513.pdf, 2020.
https://lightning.network/lightning-network-paper.pdf, 2016.
[9] Andrew[18] Antoine Riard.
Poelstra
Jonas
Nick
and
GrePinning: The good, the bad, the ugly,
gory
Sanders.
Liquid:A
bitcoinsidechain,https://lists.linuxfoundation.org/pipermail/lightning-dev/2020https://blockstream.com/assets/downloads/pdf/liquidjune/002758.html, 2020.
whitepaper.pdf, 2020.
[19] Casey
Rodarmor.
Lightning
mints,[10] Gregory Maxwell. Coincovenants using scip signatures, an amushttps://rodarmor.com/blog/lightning-mints/, 2021.
ingly bad idea, https://bitcointalk.org/index.php?topic=278122.0,
Rubin.
Checktemplateverify,[20] Jeremy
2013.
https://github.com/bitcoin/bips/blob/master/bip[11] Gregory Maxwell. Coinjoin: Bitcoin privacy for the real world,
0119.mediawiki, 2020.
https://bitcointalk.org/?topic=279249, 2013.
[21] Jeremy Rubin. Coinpool, exploring generic payment pools for fun[12] Gregory Maxwell. Coinswap: Transaction graph disjoint trustlessand privacy, https://lists.linuxfoundation.org/pipermail/bitcointrading, https://bitcointalk.org/index.php?topic=321228.0, 2013.
dev/2020-june/017968.html, 2020.
[13] Gregory
Maxwell.
Rollingcoinjoin(”joinpool”),[22] Ruben
Somsen.
Softchains:
Sidechainsashttps://gist.github.com/harding/a30864d0315a0cebd7de3732f5bd88f0,
a
soft
fork
via
proof-of-work
fraud
proofs,2020.
https://gist.github.com/rubensomsen/7ecf7f13dc2496aa7eed8815a02f13d1,[14] Malte Moser, Ittay Eyal, and Emin Gün Sirer. How to implement
2020.
secure bitcoin vaults, Feb 2016.
[23] Jacob Swambo, Spencer Hommel, Bob McElrath, and Bryan[15] Satoshi
Nakamoto.
miscchanges,
Bishop. Custody protocols using bitcoin vaults, 2020.
https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82,[24] Anthony Towns.
Tapleaf update verify covenant opcode,2010.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021september/019419.html, 2021.