path: root/35/9a179135b4d25023c8a2e7bc2e96ede873bfcf

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 85FE7C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Dec 2021 23:01:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5FD8685299
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Dec 2021 23:01:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CdNvzFgJF96Z
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Dec 2021 23:01:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 26C9485296
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Dec 2021 23:01:48 +0000 (UTC)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com
 [209.85.167.43]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BAN1kfF019301
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 10 Dec 2021 18:01:47 -0500
Received: by mail-lf1-f43.google.com with SMTP id c32so20700633lfv.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Dec 2021 15:01:47 -0800 (PST)
X-Gm-Message-State: AOAM530/NPqqReJJWTFgz8SBXyHo0F9TzDcynx3hcxJzEgosLO97nI1v
 YJq9UMEFKpiADauqVjZdAx9w+jA7Qr4kD/NEpzA=
X-Google-Smtp-Source: ABdhPJw23nvEcX2yYbLuK6ssDCqSeRWUkQNPC2gzShSMSKHtQSV/xc6TDGEY268wdoZVqXwoaVxhN4sXrlsYoueANOw=
X-Received: by 2002:ac2:4353:: with SMTP id o19mr14357473lfl.670.1639177305728; 
 Fri, 10 Dec 2021 15:01:45 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 10 Dec 2021 15:01:34 -0800
X-Gmail-Original-Message-ID: <CAD5xwhj2ncK70xjbXKeF=7oubHJs29D6Hwkt-XQxN1CG8-7Fbg@mail.gmail.com>
Message-ID: <CAD5xwhj2ncK70xjbXKeF=7oubHJs29D6Hwkt-XQxN1CG8-7Fbg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000082eda05d2d2b546"
Subject: [bitcoin-dev] [Bitcoin Advent Calendar] Payment Pools/ Coin Pools
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2021 23:01:50 -0000

--000000000000082eda05d2d2b546
Content-Type: text/plain; charset="UTF-8"

This post showcases building payment pools / coin pools* in Sapio!

https://rubin.io/bitcoin/2021/12/10/advent-13/

There will be many more posts in the series that will take this concept a
lot further and showcase some more advanced things that can be built.

I think that payment pools are incredibly exciting -- we know that it's
going to be tough to give every human a UTXO, even with Lightning. Payment
Pools promise to help compress that chain load into single utxos so that
users can be perfectly secure with a proof root and just need to do some
transactions to recover their coins. While channels could live inside of
payment pools, scaling via payment pools without nested channels can be
nice because there is no degradation of assumptions for the coins inside
being able to broadcast transactions quickly.

Payment pools in Sapio also provide a natural evolution path for things
like Rollups (they're essentially federated rollups with unilateral exits),
where state transitions in pools could one day be enforced by either
covenants or some sort of ZK system in place of N-of-N signatures.

Hopefully this stimulates some folks to muck around with Sapio and
experiment creating their own custom Payment Pools! I'd love to see someone
hack some kind of EVM into the state transition function of a payment pool
;)

Cheers,

Jeremy

* we should probably nail down some terminology -- I think Payment Pools /
Coin Pools are kinda "generic" names for the technique, but we should give
specific protocols more specific names like payment channels : lightning
network.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">This post showcases build=
ing payment pools / coin pools* in Sapio!</div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000"><a href=3D"https://rubin.io=
/bitcoin/2021/12/10/advent-13/">https://rubin.io/bitcoin/2021/12/10/advent-=
13/</a><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">There will be many more=C2=A0posts in the series that wil=
l take this concept a lot further and showcase some more advanced things th=
at=C2=A0can be built.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">I think that payment pools are incredibly excit=
ing -- we know that it&#39;s going to be tough to give every human a UTXO, =
even with Lightning. Payment Pools promise to help compress that chain load=
 into single utxos so that users can be perfectly secure with a proof root =
and just need to do some transactions to recover their coins. While channel=
s could live inside of payment pools, scaling via payment pools without nes=
ted channels can be nice because there is no degradation of assumptions for=
 the coins inside being able to broadcast transactions quickly.</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Payme=
nt pools in Sapio also provide a natural evolution path for things like Rol=
lups (they&#39;re essentially federated rollups with unilateral exits), whe=
re state transitions in pools could one day be enforced by either covenants=
 or some sort of ZK system in place of N-of-N signatures. </div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Hopefully=
 this stimulates some folks to muck around with Sapio and experiment creati=
ng their own custom Payment Pools!=C2=A0I&#39;d love to see someone hack so=
me kind of EVM into the state transition function of a payment pool ;)</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)">Cheers,</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">Jeremy</div></div><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">* we should probably nail down some terminology -=
- I think Payment Pools / Coin Pools are kinda &quot;generic&quot; names fo=
r the technique, but we should give specific protocols more specific names =
like payment channels=C2=A0: lightning network.</div><br clear=3D"all"><div=
><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatu=
re"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" targ=
et=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" t=
arget=3D"_blank"></a></div></div></div></div>

--000000000000082eda05d2d2b546--