path: root/f2/519a0edc1d2171cf0d02bcea4b29020ffec706

Return-Path: <rsomsen@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D0E04C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 22:32:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A9722403CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 22:32:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A9722403CA
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=Ju1GVYVo
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id smE_9HaM2pNt
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 22:32:31 +0000 (UTC)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com
 [IPv6:2607:f8b0:4864:20::a2b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 44F0B40142
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 22:32:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 44F0B40142
Received: by mail-vk1-xa2b.google.com with SMTP id
 71dfb90a1353d-486486d1066so218833e0c.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 15:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1692657150; x=1693261950;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=WmQvpy86XWSq5YHYOlKU/aG2UYN+iAg2xNpEjDNsPXY=;
 b=Ju1GVYVoIrWRczRL06HWkMIT4OXa+P8a019MzMEMTfk0rkRAbuo3C6Brox6Ms+4wul
 7q6EJ9hkH/LI8PQLKzz9TuYGm542AXu6zRfO8AVokur4LK8A3otafdtDnA9mWNeXsG4H
 bcx51a2E5cckb7o4X8UOnKXmgJbW9baAVkyQD95qAyCBNo0ivPpjiNJwGzLgcz0AHDhg
 VWR1LHYoBRUbJ+5Dpv1ZTKWJ30IxamzMfawnTpBWG3W3lz8huZ3AFuE2/A4KnOZdclF2
 bz6rds2twC+CDuveq5tziZ8px810Stti4q0O8zfkhWyVMmuTBtwh+NOXkp0q0MzSJD8I
 AWhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1692657150; x=1693261950;
 h=cc: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=WmQvpy86XWSq5YHYOlKU/aG2UYN+iAg2xNpEjDNsPXY=;
 b=jzPQVEln2SwyfPT0fFQC8JEeDN8zljxQBd+UgPbt1+GZlaGyr7DOC2NIOmJJp+xOmy
 wCy2QhV4cHtbWy3zSb4gzF++I4EXKT1Sf32GN4lVjB+2IQZnzYxZI2hbbTnr7s8pXnYP
 shzE3WZFiSaX9S43PWPMO9gv5C/jDsO4+5jb9aTNGipjWbKjETLS4Fa225QrRq4zETfu
 526Fiw+hjvMa3JU0piq1UcB9rwZUPhzlAio6fsztSIRMAyYKxB7MIVN89rSr/scExS90
 C65Xi4MQg28JGn8LxXOLuNhrtc4RYHMCVa/hVvDwuvZAacqEfuqEhvfNrg3uXnsRuHyd
 rcMw==
X-Gm-Message-State: AOJu0YyrqQGHkNqP3E1m0Slb0lVhZ/Cwr9ngKS6NaGymtKDXuvYgchR2
 LKWX26rz8yuTB0vDgWmeO6tjz5j9B9Mrbqm8iCs=
X-Google-Smtp-Source: AGHT+IHlt0qZ8h7p4EkphpLACIWswpzaPVuX1IzjCnA8IVUQm7eT0wfmN6KBktcTPlVerLGskTP1Q9XN1iZZgZpFOug=
X-Received: by 2002:ac5:c5c3:0:b0:48d:d6a:1a7 with SMTP id
 g3-20020ac5c5c3000000b0048d0d6a01a7mr3136308vkl.0.1692657149600; 
 Mon, 21 Aug 2023 15:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz>
 <CAPv7TjZf4nLpCZPDOWK=vJGQuH0waTXkM6h40tc7G+YKAOGOGQ@mail.gmail.com>
 <2BFA7EE8-2E0E-45A3-AC11-8E57F99EC775@breen.xyz>
In-Reply-To: <2BFA7EE8-2E0E-45A3-AC11-8E57F99EC775@breen.xyz>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 22 Aug 2023 00:32:18 +0200
Message-ID: <CAPv7TjadhWosX7=a0v+CtosmU=+uSeW_XGsaw+CiDUR=Eb9N5Q@mail.gmail.com>
To: ryan@breen.xyz
Content-Type: multipart/alternative; boundary="00000000000020e7a70603767488"
X-Mailman-Approved-At: Mon, 21 Aug 2023 22:46:21 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 21 Aug 2023 22:32:33 -0000

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

Hi Ryan,

>As I envision it, there is no cryptographic proof involved at all.

That seems to directly contradict your previous message where you stated
"[t]hey transmit invalid transactions or blocks". This transmission you
alluded to is basically a (non-optimized) fraud proof, and it assumes that
this data is actually available (unsafe assumption).

If you envision that this step is not actually needed, then users are
essentially never validating and merely relying on a set of trusted
entities. Furthermore, the idea that everyone can just pick their own set
of validators is antithetical to consensus. What if my set of validators
disagrees with your set of validators? Now one of us will reject the
Bitcoin block with the peg-out while the other will not, causing sidechain
consensus failure to directly affect the mainchain.

Cheers,
Ruben



On Sat, Aug 19, 2023 at 8:58=E2=80=AFPM <ryan@breen.xyz> wrote:

> Thank you for the feedback, Ruben. I have a question.
>
> Could you please clarify what qualifies as a fraud proof in this concept?
> As I envision it, there is no cryptographic proof involved at all.
>
> In the context of a Sentinel chain, the sidechain's full nodes monitor
> Bitcoin mempools and blocks for withdrawals that violate the rules of the
> sidechain's consensus (such as thefts or incorrect balances). When the
> sidechain's full nodes detect an invalid withdrawal on Bitcoin, they
> publish a signed attestation to a public broadcast network (Nostr in this
> case). Participating Bitcoin full nodes and miners monitor the network fo=
r
> these attestations and subsequently reject the offending transactions. Th=
e
> process doesn't involve the presentation of proof because it's a
> distributed trust relationship.
>
> While Bitcoin full nodes could decide to operate their own sidechain
> nodes, we aim not to make this a requirement (addressing the long-standin=
g
> sidechain dilemma). Bitcoin full nodes and miners wishing to participate
> can instead choose a distributed trust network comprising operators of
> sidechain full nodes that they trust. For instance, if they decide to
> follow 100 well-respected sidechain node operators, they might collective=
ly
> agree that if 75 of them issue an attestation indicating that a transacti=
on
> violates sidechain withdrawal rules, then that transaction should be deem=
ed
> invalid by their node. Withdrawals are assumed valid if no public
> attestations are present.
>
> Furthermore, I'm uncertain about what potential data availability issue
> that might arise from this. Since there are no alterations to Bitcoin
> Core's validation logic, when a full node operator starts a new node from
> the genesis block, they will validate the proof of work of the longest
> chain and remain blissfully unaware that the transactions within the bloc=
ks
> are even associated with a sidechain.
>
> On Aug 19, 2023, at 10:35 AM, Ruben Somsen <rsomsen@gmail.com> wrote:
>
> 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 describ=
e
> here is known as "fraud proofs". The crucial problem it doesn't address i=
s
> "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 ca=
n
> succinctly reveal erroneous steps (e.g. 1+1=3D3), thus convincing everyon=
e
> 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 frau=
d
> proofs, but what if nobody has the data?
>
> When someone claims data is unavailable, the only way to verify this clai=
m
> 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 clai=
m
> 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 m=
e
>> 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/222480
>>
>> 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 with=
out
>> 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, t=
he
>> 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 a=
re
>> 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 t=
he
>> extent of automation. Nonetheless, I believe we now possess tools that c=
an
>> 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 moni=
tor
>> 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 Nost=
r
>> servers. Bitcoin full nodes wishing to partake in sidechain consensus ca=
n
>> run a small daemon alongside Bitcoin Core. This daemon can monitor publi=
c
>> 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
>> receive updates from Nostr. For instance, a full node might choose to tr=
ust
>> 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.
>> Instead of requiring nodes to monitor sidechains, sidechains now monitor
>> nodes. In this sense, it is akin to drivechains, with the difference bei=
ng
>> that peg-outs could be instantaneous and individual, without the need fo=
r
>> the three-month gradual social consensus. Furthermore, a single daemon c=
an
>> be configured to monitor notifications from any number of Sentinel chain=
s,
>> 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 (mor=
e
>> 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 othe=
r
>> forms of two-way pegs, primarily in terms of speed and efficiency of
>> consensus. Moreover, they align more closely with Bitcoin's principles b=
y
>> 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 fulfill=
ing
>> 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
>>
>
>

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

<div dir=3D"ltr">Hi Ryan,<div><br></div><div>&gt;As I envision it, there is=
 no cryptographic proof involved at all.</div><div><br></div><div>That seem=
s to directly contradict your previous message where you stated &quot;[t]he=
y transmit invalid transactions or blocks&quot;. This transmission you allu=
ded to is basically a (non-optimized) fraud proof, and it assumes that this=
 data is actually available (unsafe assumption).</div><div><br></div><div>I=
f you envision that this step is not actually needed, then users are essent=
ially never validating and merely relying on a set of trusted entities. Fur=
thermore, the idea that everyone can just pick their own set of validators =
is antithetical to consensus. What if my set of validators disagrees with y=
our set of validators? Now one of us will reject the Bitcoin block with the=
 peg-out while the other will not, causing sidechain consensus failure to d=
irectly affect the mainchain.</div><div></div><div><br></div><div>Cheers,</=
div><div>Ruben</div><div><br></div><div><br></div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 19, 2023 at 8=
:58=E2=80=AFPM &lt;<a href=3D"mailto:ryan@breen.xyz">ryan@breen.xyz</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><di=
v><div>Thank you for the feedback, Ruben. I have a question.</div><div><br>=
</div><div>Could you please clarify what qualifies as a fraud proof in this=
 concept? As I envision it, there is no cryptographic proof involved at all=
.</div><div><br></div><div>In the context of a Sentinel chain, the sidechai=
n&#39;s full nodes monitor Bitcoin mempools and blocks for withdrawals that=
 violate the rules of the sidechain&#39;s consensus (such as thefts or inco=
rrect balances). When the sidechain&#39;s full nodes detect an invalid with=
drawal on Bitcoin, they publish a signed attestation to a public broadcast =
network (Nostr in this case). Participating Bitcoin full nodes and miners m=
onitor the network for these attestations and subsequently reject the offen=
ding transactions. The process doesn&#39;t involve the presentation of proo=
f because it&#39;s a distributed trust relationship.</div><div><br></div><d=
iv>While Bitcoin full nodes could decide to operate their own sidechain nod=
es, we aim not to make this a requirement (addressing the long-standing sid=
echain dilemma). Bitcoin full nodes and miners wishing to participate can i=
nstead choose a distributed trust network comprising operators of sidechain=
 full nodes that they trust. For instance, if they decide to follow 100 wel=
l-respected sidechain node operators, they might collectively agree that if=
 75 of them issue an attestation indicating that a transaction violates sid=
echain withdrawal rules, then that transaction should be deemed invalid by =
their node. Withdrawals are assumed valid if no public attestations are pre=
sent.</div><div><br></div><div>Furthermore, I&#39;m uncertain about what po=
tential data availability issue that might arise from this. Since there are=
 no alterations to Bitcoin Core&#39;s validation logic, when a full node op=
erator starts a new node from the genesis block, they will validate the pro=
of of work of the longest chain and remain blissfully unaware that the tran=
sactions within the blocks are even associated with a sidechain.</div><div>=
<br><blockquote type=3D"cite"><div>On Aug 19, 2023, at 10:35 AM, Ruben Soms=
en &lt;<a href=3D"mailto:rsomsen@gmail.com" target=3D"_blank">rsomsen@gmail=
.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr">Hi Ryan,<br><br>Thanks f=
or taking the time to write a proposal. As is often the case, these ideas a=
ren&#39;t actually as novel as you might think. What you describe here is k=
nown as &quot;fraud proofs&quot;. The crucial problem it doesn&#39;t addres=
s is &quot;data availability&quot;.<br><br>The general idea behind fraud pr=
oofs is that if you commit to every computational step (note Bitcoin curren=
tly doesn&#39;t, but could), anyone can succinctly reveal erroneous steps (=
e.g. 1+1=3D3), thus convincing everyone the state transition (i.e. block) i=
s invalid. This works if a bunch of people have all the data and are willin=
g to construct and spread the fraud proofs, but what if nobody has the data=
?<br><br>When someone claims data is unavailable, the only way to verify th=
is claim is by downloading the data. You can&#39;t just ban this peer for f=
alse claims either, since the data might have actually been unavailable whe=
n the claim was made but then became available. In essence this means malic=
ious peers can cause you to download all data, meaning you effectively have=
n&#39;t saved any bandwidth.<br><br>It should be noted that fraud proofs co=
uld 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.<br><br>As a bit of history, fraud proo=
fs were actually briefly considered for inclusion into segwit, but were aba=
ndoned due to the data availability issue: <a href=3D"https://bitcoincore.o=
rg/en/2016/01/26/segwit-benefits/#update-2016-10-19" target=3D"_blank">http=
s://bitcoincore.org/en/2016/01/26/segwit-benefits/#update-2016-10-19</a><br=
><br>And finally, there is a way to address the data availability issue, wh=
ich I describe here (PoW fraud proofs/softchains, though note I am currentl=
y of the opinion it&#39;s better used for low-bandwidth mainchain nodes ins=
tead of for sidechains): <a href=3D"https://gist.github.com/RubenSomsen/7ec=
f7f13dc2496aa7eed8815a02f13d1" target=3D"_blank">https://gist.github.com/Ru=
benSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</a><br><br>In theory you can als=
o 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>Ru=
ben<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" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">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.<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"_b=
lank">breen.xyz</a><br>
Web: <a href=3D"https://ursus.camp/" rel=3D"noreferrer" target=3D"_blank">h=
ttps://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>
</div></blockquote></div><br></div></div></blockquote></div>

--00000000000020e7a70603767488--