In February 2022, Gleb Naumenko (Bitmex grant recipient) and Antoine Riard posted a CoinPool whitepaper. The earlier version of the project received less technical coverage in Bitcoin Magazine. This post attempts to build up some intuition on the CoinPool proposal by answering questions based on the feedback. It is aimed at slightly-technical readers (those, who know what a payment channel is), who lack time or expertise to read a full paper. We hope that this article spawns more feedback from the readers, which can be sent as a response to the mailing list post or to Gleb directly via gleb@thelab31.xyz.
What is CoinPool?
It is a protocol on top of Bitcoin: many Bitcoin users lock their funds in a single UTXO, transact within this UTXO off-chain, and are able to unlock/withdraw their funds from the pool at any time.
A CoinPool instance can be seen as a multi-party payment channel with uplifting we will discuss below.
How would Bitcoin benefit from CoinPool?
CoinPool allows making more Bitcoin payments with lower fees, instant confirmation, and an alternative approach to privacy.
Those who don’t utilize CoinPool get more block space from the savings achieved by CoinPool, which lets them make their transactions at a lower cost.
How does CoinPool compare to Lightning?
CoinPool utilizes the block space more efficiently because users can make more payments before they have to close channels via an on-chain transaction. This is achieved by avoiding routing across the (Lightning) Network which results in better funds liquidity.
The major downside of CoinPool is that every action (except withdrawal) requires cooperation from all pool users. We aim to approach this downside with future research. In some cases, this issue is already solved with uplifting.
What is CoinPool uplifting?
CoinPool accounts can represent not only simple balances but also any Bitcoin protocols. The process of bringing a protocol instance to a CoinPool account is called uplifting.
For example, it could be a 2-user payment channel, connected to the Lightning Network. In this case, payments between the two users, and from them to the LN, don’t require cooperation from other participants.
Uplifted protocol instances adhere to a very similar threat model as their non-uplifted versions.
How does CoinPool compare to Channel Factories?
CoinPool and Channel Factories optimize the LN in a similar way, by utilizing the block space more efficiently.
Unlike CoinPool, one user withdrawing from a Channel Factory forces all other users to leave, which significantly bounds potential savings.
How does CoinPool compare to JoinPool?
JoinPool is a CoinPool predecessor, which does not support off-chain payments, uplifting, and introduces higher communication/storage overhead.
The main purpose of JoinPool is not scalability, but anonymity achieved via coin mixing.
Could CoinPool be used today?
No. The simplest CoinPool version requires SIGHASH_ANYPREVOUT, which is anticipated by many to be the next Bitcoin soft fork. However, even this is not enough in practice: it would not be scalable beyond 20 users and would require balances with uniform amounts.
What has to be done to make CoinPool practical?
There are different ways to implement CoinPool. In addition to SIGHASH_ANYPREVOUT, our CoinPool version requires SIGHASH_GROUP and OP_MERKLESUB. The former is currently discussed by the Lightning community to solve their protocol issues, while the latter is a novel opcode proposed by our team.
What is OP_MERKLESUB?
It is a new opcode that enables covenants (rules restricting how certain coins could be spent). This opcode forces the output to be equal to the Taproot output being spent, but with the signing key being removed from the Taproot tree and the Taproot internal pubkey.
In CoinPool, it enables non-cooperative withdrawal preserving the remaining pool state.
Can OP_MERKLESUB be useful for something besides CoinPool?
Merkle tree subtraction could be useful for other smart contracts as well, but we leave this direction for future research. OP_MERKLESUB is somewhat special, as it also enforces modifying the key path along with the script path.
What else can be used to build CoinPool?
OP_CTV allows building payment pools with different trade-offs, which we personally find less interesting than OP_MERKLESUB design. Adding more general-purpose opcodes on top of OP_CTV could enable something very similar to CoinPool. OP_TLUV could be seen as an extended version of OP_MERKLESUB, but it requires more protocol design work to build a CoinPool-like protocol.
What are the next steps in CoinPool development?
One direction is to solve the main CoinPool limitation, high interactivity requirement. We already see some solutions, which are based on game theory or minimal trust assumptions, but we seek something better.
At the same time, now that there are many proposals for covenants and future soft forks (OP_CTV, OP_TLUV, OP_EVICT), we should develop a framework for comparing them, to better understand the trade-off and inform the ecosystem decisions on moving forward.