path: root/9e/1ef891baa2f928f4ce2659c9505402e6ebe524

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&#39;t actually as novel as you=
 might think. What you describe here is known as &quot;fraud proofs&quot;. =
The crucial problem it doesn&#39;t address is &quot;data availability&quot;=
.<br><br>The general idea behind fraud proofs is that if you commit to ever=
y computational step (note Bitcoin currently doesn&#39;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&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;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&#39;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--