MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 21 Feb 2022 08:16:06 -0500
Message-ID: <CALZpt+E+eKKtOXd-8A6oThw-1i5cJ4h12TuG8tnWswqbfAnRdA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b05ef505d8870928"
Subject: [bitcoin-dev] A Dive into CoinPool : Bitcoin Balances for Billions
Precedence: list

--000000000000b05ef505d8870928
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=9Cin-depth=E2=80=9D: what kind of proto=
col 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.ht=
ml
[1] Always have a backup plan in Bitcoin :
https://github.com/coinpool-dev/paper/blob/master/coinpool-v0.1.pdf

--000000000000b05ef505d8870928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>We (Gleb+ me) would like to present the followi=
ng of our research on payment pools [0].<br><br>Abstract:<br><br>CoinPool i=
s a new multi-party construction to improve Bitcoin onboarding and transact=
ional scaling by orders of magnitude.<br>CoinPool allows many users to shar=
e a UTXO and make instant off-chain transfers inside the UTXO while allowin=
g withdrawals at any time without permission from other users.<br>In-pool a=
ccounts can be used for advanced protocols (e.g., payment channels). Connec=
ting them to other CoinPool instances, or even to the Lightning Network, ma=
kes in-pool funds highly liquid.<br>CoinPool construction relies on SIGHASH=
_GROUP, SIGHASH_ANYPREVOUT and OP_MERKLESUB changes to Bitcoin. It also ass=
umes a high degree of interactivity between pool participants.<br><br>CoinP=
ool provides an interesting alternative to the LN: it allows locking more p=
eople 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.<br>CoinPool accounts can be also plugged into the LN, =
making them complementary and benefiting from each other.<br><br>CoinPool e=
xplores what can be achieved with covenants, lately explored by a few of us=
. It is exploration =E2=80=9Cin-depth=E2=80=9D: what kind of protocol could=
 be achieved by Merkle tree subtraction check.<br>We hope this work can inf=
orm thinking on future softforks.<br><br>We think the 7.9 billion people co=
uld be distributed across 1000-sized CoinPool instances. Assuming perfect c=
ooperation among the participant, a liquidity exhaustion rate of 6 months a=
nd a refulfillment footprint of 100 inputs (at 106 bytes each), 167 GB of b=
lockchain space would be required by year to enable everyone in the world t=
o transact on Bitcoin in a non-custodial fashion, unless one order of magni=
tude beyond the current block size. By fine-tuning the pools off-chain sust=
ainability=C2=A0 parameters further, it is realistic to think to satisfy cu=
rrent full-node validation requirements, thus preserving the decentralizati=
on of the network.<br>.<br><div>We&#39;re eager to hear everyone&#39;s feed=
back, what we missed, what can be improved. We hope the ideas presented sou=
nd 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 w=
ild.<br></div><br>The paper is available here :<br><a href=3D"https://coinp=
ool.dev/v0.1.pdf">https://coinpool.dev/v0.1.pdf</a> [1]<br><br>The OP_MERKL=
ESUB and SIGASH_GROUP BIPs are available here:<br><a href=3D"https://github=
.com/ariard/bips/blob/coinpool-bips/bip-group.mediawiki">https://github.com=
/ariard/bips/blob/coinpool-bips/bip-group.mediawiki</a><br><a href=3D"https=
://github.com/ariard/bips/blob/coinpool-bips/bip-merklesub.mediawiki">https=
://github.com/ariard/bips/blob/coinpool-bips/bip-merklesub.mediawiki</a><br=
><br>The code for the pool withdraw tree is available here:<br><a href=3D"h=
ttps://github.com/ariard/bitcoin/tree/2022-02-coinpool-withdraw">https://gi=
thub.com/ariard/bitcoin/tree/2022-02-coinpool-withdraw</a><br><br>The trans=
action/scripts formats for the CoinPool transaction are available here:<br>=
<a href=3D"https://gist.github.com/ariard/713ce396281163337c175d9122163e8f"=
>https://gist.github.com/ariard/713ce396281163337c175d9122163e8f</a><br><br=
>Sincerely,<br>Gleb &amp; Antoine<br><br>PS: Thanks to the reviewers.<br><b=
r>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-June/017964.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2020-June/017964.html</a><br>[1] Always have a backup plan in Bitcoin : <=
a href=3D"https://github.com/coinpool-dev/paper/blob/master/coinpool-v0.1.p=
df">https://github.com/coinpool-dev/paper/blob/master/coinpool-v0.1.pdf</a>=
</div>

--000000000000b05ef505d8870928--