Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 85FE7C0012 for ; 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 ; 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 ; 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 ; 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 ; Fri, 10 Dec 2021 18:01:47 -0500 Received: by mail-lf1-f43.google.com with SMTP id c32so20700633lfv.4 for ; 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 Date: Fri, 10 Dec 2021 15:01:34 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --000000000000082eda05d2d2b546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This post showcases build= ing payment pools / coin pools* in Sapio!

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

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.

I think that payment pools are incredibly excit= ing -- 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 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.

Payme= nt pools in Sapio also provide a natural evolution path for things like Rol= lups (they'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.

Hopefully= this stimulates some folks to muck around with Sapio and experiment creati= ng their own custom Payment Pools!=C2=A0I'd love to see someone hack so= me 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 fo= r the technique, but we should give specific protocols more specific names = like payment channels=C2=A0: lightning network.

--000000000000082eda05d2d2b546--