[bitcoin-dev] A Dive into CoinPool : Bitcoin Balances for Billions

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3157 bytes --]

Hi,

We (Gleb+ me) would like to present the following of our research on
payment pools [0].

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 make instant 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-pool funds highly liquid.
CoinPool construction relies on SIGHASH_GROUP, SIGHASH_ANYPREVOUT and
OP_MERKLESUB changes to Bitcoin. It also assumes a high degree of
interactivity between pool participants.

CoinPool provides an interesting alternative to the LN: it allows locking
more people in a single UTXO and potentially lets them stay in the same
UTXO for longer. In the end, this expands Bitcoin payment throughput, via
better use of the block space.
CoinPool accounts can be also plugged into the LN, making them
complementary and benefiting from each other.

CoinPool explores what can be achieved with covenants, lately explored by a
few of us. It is exploration “in-depth”: what kind of protocol could be
achieved by Merkle tree subtraction check.
We hope this work can inform thinking on future softforks.

We think the 7.9 billion people could be distributed across 1000-sized
CoinPool instances. Assuming perfect cooperation among the participant, a
liquidity exhaustion rate of 6 months and a refulfillment footprint of 100
inputs (at 106 bytes each), 167 GB of blockchain space would be required by
year to enable everyone in the world to transact on Bitcoin in a
non-custodial fashion, unless one order of magnitude beyond the current
block size. By fine-tuning the pools off-chain sustainability  parameters
further, it is realistic to think to satisfy current full-node validation
requirements, thus preserving the decentralization of the network.
.
We're eager to hear everyone's feedback, what we missed, what can be
improved. We hope the ideas presented sound interesting to the community.
If so, we acknowledge it will likely take a decade of patient engineering
before we see mature payment pools in the wild.

The paper is available here :
https://coinpool.dev/v0.1.pdf [1]

The OP_MERKLESUB and SIGASH_GROUP BIPs are available here:
https://github.com/ariard/bips/blob/coinpool-bips/bip-group.mediawiki
https://github.com/ariard/bips/blob/coinpool-bips/bip-merklesub.mediawiki

The code for the pool withdraw tree is available here:
https://github.com/ariard/bitcoin/tree/2022-02-coinpool-withdraw

The transaction/scripts formats for the CoinPool transaction are available
here:
https://gist.github.com/ariard/713ce396281163337c175d9122163e8f

Sincerely,
Gleb & Antoine

PS: Thanks to the reviewers.

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[1] Always have a backup plan in Bitcoin :
https://github.com/coinpool-dev/paper/blob/master/coinpool-v0.1.pdf

[-- Attachment #2: Type: text/html, Size: 3801 bytes --]