diff options
| author | Ruben Somsen <rsomsen@gmail.com> | 2023-08-19 16:35:10 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-08-19 14:35:24 +0000 |
| commit | ec6cbd2d76f75fc920f43028b0d51d3b18a5a6b7 (patch) | |
| tree | 6afd91e57aabd950ee6bb3a388c2dfedcc8d1f24 | |
| parent | 42c376dce0215ec67b9c0c2a2b79a939d7fb4ab6 (diff) | |
| download | pi-bitcoindev-ec6cbd2d76f75fc920f43028b0d51d3b18a5a6b7.tar.gz pi-bitcoindev-ec6cbd2d76f75fc920f43028b0d51d3b18a5a6b7.zip | |
Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
| -rw-r--r-- | 9e/1ef891baa2f928f4ce2659c9505402e6ebe524 | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/9e/1ef891baa2f928f4ce2659c9505402e6ebe524 b/9e/1ef891baa2f928f4ce2659c9505402e6ebe524 new file mode 100644 index 000000000..c276c57a8 --- /dev/null +++ b/9e/1ef891baa2f928f4ce2659c9505402e6ebe524 @@ -0,0 +1,395 @@ +Return-Path: <rsomsen@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 797B5C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Aug 2023 14:35:24 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 51604416E3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Aug 2023 14:35:24 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 51604416E3 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20221208 header.b=MDhqtrW5 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.099 +X-Spam-Level: +X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=no autolearn_force=no +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Fi_15F142-AG + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Aug 2023 14:35:22 +0000 (UTC) +Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com + [IPv6:2607:f8b0:4864:20::934]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 0914B41675 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Aug 2023 14:35:21 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0914B41675 +Received: by mail-ua1-x934.google.com with SMTP id + a1e0cc1a2514c-78705fcb8d7so115708241.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 19 Aug 2023 07:35:21 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20221208; t=1692455721; x=1693060521; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :from:to:cc:subject:date:message-id:reply-to; + bh=/lDwzW8OyVPVN2FKPT2nxdWk0vESxNSU3WFDpA9lSGU=; + b=MDhqtrW5k2V2JF8d2yZhOxvWXsaUeE4BmzIXK4K24WQZ63FFm9l9Be9/Osdix3mP5G + 9PpY2F+Shc/hGaI5MKEgRj1BEbfSAeeJke9jhk9P8qmAq9ChgQ3sk56Rs9wVSUS6kDVG + sw+mBljj1AvlDGku5p07VurphGmCjdXxiI6gapkmKqfsZINiMekUrXo3XvkPuuNnn2Nt + e2xVYm77dPACury2kvJdNxz0RexYhvxZslRs3aIVV8P6207PYSiDpikjVaJRo7CRcT2g + bnexU9sdm57YypqPp1Vsr4Cap63UXhfB192DmTPP2e82i1Kakt73xrWK9wL86T1xnevx + mw+Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20221208; t=1692455721; x=1693060521; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; + bh=/lDwzW8OyVPVN2FKPT2nxdWk0vESxNSU3WFDpA9lSGU=; + b=TuxWgIstn3oYi+aRnLBQTzEgoka1quELe+OENdiLqHGgyUVUmgjBxBJqfH/Mnq0b27 + dEHuf/RRJWl6jgZhkXKP7gDQl7XDAF8YcmQdRhVf+xH+elD55rZrZORAdk4BxYIi4a2M + VPITgY6M9erHIOUiTqsm7eXByx9u3x2hMi7Le/4S0I4PFH92RVpwU6f03qfRhhBKB6jr + jnyCv1UdrL/65NXiEd+FmfdtNIC5EwOeTXgkra1W/m4LtTfAnECI1scW90ffM9W0K+G0 + 4C/ORU2RyD6+psoS2oql3OBbRxtSCiEap7WveopBeJQwnvV6X8u3GrjfVv/yIpllNw/H + 1eOQ== +X-Gm-Message-State: AOJu0YwMiU1EkpZXejeGFWNytoBdPh5SyhAs5AsU38BpYl/GgUDcvna4 + DyedPiXKydrguOpveS+A/weMuOf8iAXY6Wq33/A= +X-Google-Smtp-Source: AGHT+IEALY/zVU2QLOdTqMTbFJHKwl1K1htIfEUgR+rUFmJBxlZgD4eaLX/M6+OIYIzd2HFF8CjFqTdMt+CjmN0NT8g= +X-Received: by 2002:a05:6102:3589:b0:447:83e6:f8a with SMTP id + h9-20020a056102358900b0044783e60f8amr1002819vsu.2.1692455720579; Sat, 19 Aug + 2023 07:35:20 -0700 (PDT) +MIME-Version: 1.0 +References: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz> +In-Reply-To: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz> +From: Ruben Somsen <rsomsen@gmail.com> +Date: Sat, 19 Aug 2023 16:35:10 +0200 +Message-ID: <CAPv7TjZf4nLpCZPDOWK=vJGQuH0waTXkM6h40tc7G+YKAOGOGQ@mail.gmail.com> +To: ryan@breen.xyz, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000005f80e0603478ee6" +X-Mailman-Approved-At: Sat, 19 Aug 2023 14:35:42 +0000 +Subject: Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg +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: Sat, 19 Aug 2023 14:35:24 -0000 + +--00000000000005f80e0603478ee6 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Ryan, + +Thanks for taking the time to write a proposal. As is often the case, these +ideas aren't actually as novel as you might think. What you describe here +is known as "fraud proofs". The crucial problem it doesn't address is "data +availability". + +The general idea behind fraud proofs is that if you commit to every +computational step (note Bitcoin currently doesn't, but could), anyone can +succinctly reveal erroneous steps (e.g. 1+1=3D3), thus convincing everyone +the state transition (i.e. block) is invalid. This works if a bunch of +people have all the data and are willing to construct and spread the fraud +proofs, but what if nobody has the data? + +When someone claims data is unavailable, the only way to verify this claim +is by downloading the data. You can't just ban this peer for false claims +either, since the data might have actually been unavailable when the claim +was made but then became available. In essence this means malicious peers +can cause you to download all data, meaning you effectively haven't saved +any bandwidth. + +It should be noted that fraud proofs could still reduce the need for +computation (i.e. you download all data, but only verify the parts for +which you receive fraud notifications), so it can still provide some form +of scaling. + +As a bit of history, fraud proofs were actually briefly considered for +inclusion into segwit, but were abandoned due to the data availability +issue: +https://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016-10-19 + +And finally, there is a way to address the data availability issue, which I +describe here (PoW fraud proofs/softchains, though note I am currently of +the opinion it's better used for low-bandwidth mainchain nodes instead of +for sidechains): +https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1 + +In theory you can also do data availability sampling through the use of +erasure codes, but that gets very complex and brittle. + +Hope this helps. + +Cheers, +Ruben + +On Sat, Aug 19, 2023 at 4:29=E2=80=AFPM Ryan Breen via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Recent discussions on social media regarding drivechains have prompted me +> to consider the implementation of a two-way sidechain peg within the +> Bitcoin protocol. I would like to propose what I believe may be a novel +> solution to this issue. +> +> I have previously written about here on my blog: +> https://ursus.camp/bitcoin/2023/08/10/sidechains.html +> And here is the Stacker News discussion: https://stacker.news/items/22248= +0 +> +> Nevertheless, I will hit the high points of the concept here: +> +> The most challenging problem that BIP-300 aims to address is how to +> establish a two-way peg without involving a multisig federation and witho= +ut +> requiring miners and full nodes to possess knowledge about the sidechain = +or +> run a sidechain node. This is, in fact, a very difficult nut to crack. +> +> The method adopted by BIP-300 involves conducting sidechain withdrawals +> directly through the miners. To prevent miners from engaging in theft, th= +e +> proposal mandates a three-month period for peg-outs, during which all +> miners vote on the peg-out. The intention here is to allow the community = +to +> respond in the event of an incorrect peg-out or theft. The miners are +> expected to be responsive to community pressure and make the correct +> decisions. To streamline this process of social consensus, withdrawals ar= +e +> grouped into one large bundle per three month period. +> +> Despite criticisms of this proposal, I find it to be a viable and likely +> effective solution. After all, Bitcoin's underlying mechanism is +> fundamentally rooted in social consensus, with the only question being th= +e +> extent of automation. Nonetheless, I believe we now possess tools that ca= +n +> improve this process, leading to the concept of Sentinel chains. +> +> The core idea is that sidechain nodes function as Sentinels, notifying +> full nodes of thefts via a secondary network. These sidechain nodes monit= +or +> the current state of Bitcoin blocks and mempool transactions, actively +> searching for peg-outs that contravene sidechain consensus in order to +> steal funds. They transmit invalid transactions or blocks to public Nostr +> servers. Bitcoin full nodes wishing to partake in sidechain consensus can +> run a small daemon alongside Bitcoin Core. This daemon can monitor public +> Nostr nodes for messages about invalid transactions and then instruct +> Bitcoin Core, via RPC calls, to ignore and not forward those invalid +> transactions. +> +> Full nodes can choose any group of individuals or organizations to receiv= +e +> updates from Nostr. For instance, a full node might choose to trust a +> collective of 100 sidechain nodes consisting of a mix of prominent +> companies and individuals in the sidechain's sphere. Rather than relying = +on +> a single trusted group, full nodes form their own decentralized web of +> trust. +> +> This reverses the conventional model of two-way pegged sidechains. Instea= +d +> of requiring nodes to monitor sidechains, sidechains now monitor nodes. I= +n +> this sense, it is akin to drivechains, with the difference being that +> peg-outs could be instantaneous and individual, without the need for the +> three-month gradual social consensus. Furthermore, a single daemon can be +> configured to monitor notifications from any number of Sentinel chains, +> rendering this solution highly scalable for numerous sidechains. +> +> In summary, drivechains: +> +> - Require an initial consensus soft fork +> - Treat each new sidechain as a miner-activated soft fork (easier to +> deploy but more centralized) +> - Feature withdrawals occurring in three-month periods +> - Involve withdrawals in bundles +> - Exclude Bitcoin full nodes from participation in sidechain consensus +> - Are currently production-ready +> +> Sentinel chains: +> +> - Require no initial soft fork of any kind +> - Permit each new sidechain to be miner-activated OR user-activated (more +> challenging to deploy but more decentralized) +> - Allow instantaneous withdrawals +> - Facilitate individual withdrawals +> - Enable Bitcoin full nodes to engage in consensus +> - Are only at the concept stage +> +> Sentinel chains could potentially offer substantial advantages over other +> forms of two-way pegs, primarily in terms of speed and efficiency of +> consensus. Moreover, they align more closely with Bitcoin's principles by +> ensuring that power remains within the realm of full nodes. Lastly, they +> shield Core-only users from potential bug consequences stemming from +> consensus changes directly implemented in Bitcoin Core, possibly fulfilli= +ng +> the long-awaited promise of a fully opt-in soft fork. +> +> +> Ryan Breen +> Twitter: ursuscamp +> Email: ryan @ breen.xyz +> Web: https://ursus.camp +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000005f80e0603478ee6 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Ryan,<br><br>Thanks for taking the time to write a prop= +osal. As is often the case, these ideas aren't actually as novel as you= + might think. What you describe here is known as "fraud proofs". = +The crucial problem it doesn't address is "data availability"= +.<br><br>The general idea behind fraud proofs is that if you commit to ever= +y computational step (note Bitcoin currently doesn't, but could), anyon= +e can succinctly reveal erroneous steps (e.g. 1+1=3D3), thus convincing eve= +ryone the state transition (i.e. block) is invalid. This works if a bunch o= +f people have all the data and are willing to construct and spread the frau= +d proofs, but what if nobody has the data?<br><br>When someone claims data = +is unavailable, the only way to verify this claim is by downloading the dat= +a. You can't just ban this peer for false claims either, since the data= + might have actually been unavailable when the claim was made but then beca= +me available. In essence this means malicious peers can cause you to downlo= +ad all data, meaning you effectively haven't saved any bandwidth.<br><b= +r>It should be noted that fraud proofs could still reduce the need for comp= +utation (i.e. you download all data, but only verify the parts for which yo= +u receive fraud notifications), so it can still provide some form of scalin= +g.<br><br>As a bit of history, fraud proofs were actually briefly considere= +d for inclusion into segwit, but were abandoned due to the data availabilit= +y issue: <a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-benefits/#= +update-2016-10-19">https://bitcoincore.org/en/2016/01/26/segwit-benefits/#u= +pdate-2016-10-19</a><br><br>And finally, there is a way to address the data= + availability issue, which I describe here (PoW fraud proofs/softchains, th= +ough note I am currently of the opinion it's better used for low-bandwi= +dth mainchain nodes instead of for sidechains): <a href=3D"https://gist.git= +hub.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1">https://gist.github.c= +om/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</a><br><br>In theory you ca= +n also do data availability sampling through the use of erasure codes, but = +that gets very complex and brittle.<br><br>Hope this helps.<br><br>Cheers,<= +br>Ruben<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"= +gmail_attr">On Sat, Aug 19, 2023 at 4:29=E2=80=AFPM Ryan Breen via bitcoin-= +dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de= +v@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gm= +ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= +204,204);padding-left:1ex">Recent discussions on social media regarding dri= +vechains have prompted me to consider the implementation of a two-way sidec= +hain peg within the Bitcoin protocol. I would like to propose what I believ= +e may be a novel solution to this issue.<br> +<br> +I have previously written about here on my blog: <a href=3D"https://ursus.c= +amp/bitcoin/2023/08/10/sidechains.html" rel=3D"noreferrer" target=3D"_blank= +">https://ursus.camp/bitcoin/2023/08/10/sidechains.html</a><br> +And here is the Stacker News discussion: <a href=3D"https://stacker.news/it= +ems/222480" rel=3D"noreferrer" target=3D"_blank">https://stacker.news/items= +/222480</a><br> +<br> +Nevertheless, I will hit the high points of the concept here:<br> +<br> +The most challenging problem that BIP-300 aims to address is how to establi= +sh a two-way peg without involving a multisig federation and without requir= +ing miners and full nodes to possess knowledge about the sidechain or run a= + sidechain node. This is, in fact, a very difficult nut to crack.<br> +<br> +The method adopted by BIP-300 involves conducting sidechain withdrawals dir= +ectly through the miners. To prevent miners from engaging in theft, the pro= +posal mandates a three-month period for peg-outs, during which all miners v= +ote on the peg-out. The intention here is to allow the community to respond= + in the event of an incorrect peg-out or theft. The miners are expected to = +be responsive to community pressure and make the correct decisions. To stre= +amline this process of social consensus, withdrawals are grouped into one l= +arge bundle per three month period.<br> +<br> +Despite criticisms of this proposal, I find it to be a viable and likely ef= +fective solution. After all, Bitcoin's underlying mechanism is fundamen= +tally rooted in social consensus, with the only question being the extent o= +f automation. Nonetheless, I believe we now possess tools that can improve = +this process, leading to the concept of Sentinel chains.<br> +<br> +The core idea is that sidechain nodes function as Sentinels, notifying full= + nodes of thefts via a secondary network. These sidechain nodes monitor the= + current state of Bitcoin blocks and mempool transactions, actively searchi= +ng for peg-outs that contravene sidechain consensus in order to steal funds= +. They transmit invalid transactions or blocks to public Nostr servers. Bit= +coin full nodes wishing to partake in sidechain consensus can run a small d= +aemon alongside Bitcoin Core. This daemon can monitor public Nostr nodes fo= +r messages about invalid transactions and then instruct Bitcoin Core, via R= +PC calls, to ignore and not forward those invalid transactions.<br> +<br> +Full nodes can choose any group of individuals or organizations to receive = +updates from Nostr. For instance, a full node might choose to trust a colle= +ctive of 100 sidechain nodes consisting of a mix of prominent companies and= + individuals in the sidechain's sphere. Rather than relying on a single= + trusted group, full nodes form their own decentralized web of trust.<br> +<br> +This reverses the conventional model of two-way pegged sidechains. Instead = +of requiring nodes to monitor sidechains, sidechains now monitor nodes. In = +this sense, it is akin to drivechains, with the difference being that peg-o= +uts could be instantaneous and individual, without the need for the three-m= +onth gradual social consensus. Furthermore, a single daemon can be configur= +ed to monitor notifications from any number of Sentinel chains, rendering t= +his solution highly scalable for numerous sidechains.<br> +<br> +In summary, drivechains:<br> +<br> +- Require an initial consensus soft fork<br> +- Treat each new sidechain as a miner-activated soft fork (easier to deploy= + but more centralized)<br> +- Feature withdrawals occurring in three-month periods<br> +- Involve withdrawals in bundles<br> +- Exclude Bitcoin full nodes from participation in sidechain consensus<br> +- Are currently production-ready<br> +<br> +Sentinel chains:<br> +<br> +- Require no initial soft fork of any kind<br> +- Permit each new sidechain to be miner-activated OR user-activated (more c= +hallenging to deploy but more decentralized)<br> +- Allow instantaneous withdrawals<br> +- Facilitate individual withdrawals<br> +- Enable Bitcoin full nodes to engage in consensus<br> +- Are only at the concept stage<br> +<br> +Sentinel chains could potentially offer substantial advantages over other f= +orms of two-way pegs, primarily in terms of speed and efficiency of consens= +us. Moreover, they align more closely with Bitcoin's principles by ensu= +ring that power remains within the realm of full nodes. Lastly, they shield= + Core-only users from potential bug consequences stemming from consensus ch= +anges directly implemented in Bitcoin Core, possibly fulfilling the long-aw= +aited promise of a fully opt-in soft fork.<br> +<br> +<br> +Ryan Breen<br> +Twitter: ursuscamp<br> +Email: ryan @ <a href=3D"http://breen.xyz" rel=3D"noreferrer" target=3D"_bl= +ank">breen.xyz</a><br> +Web: <a href=3D"https://ursus.camp" rel=3D"noreferrer" target=3D"_blank">ht= +tps://ursus.camp</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000005f80e0603478ee6-- + |