path: root/eb/e1f27dcd62f3826e44a6631853605bb93be95e

Return-Path: <ryan@breen.xyz>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 21DECC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Aug 2023 18:58:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id F0D8780BE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Aug 2023 18:58:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F0D8780BE4
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=breen.xyz header.i=@breen.xyz header.a=rsa-sha256
 header.s=sig1 header.b=SGcs0BPD
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level: 
X-Spam-Status: No, score=-0.299 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, FROM_SUSPICIOUS_NTLD=0.499,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=no 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 uqBULcO3ih3f
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Aug 2023 18:58:30 +0000 (UTC)
Received: from st43p00im-ztbu10063601.me.com (st43p00im-ztbu10063601.me.com
 [17.58.63.174])
 by smtp1.osuosl.org (Postfix) with ESMTPS id CFE6081EF1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Aug 2023 18:58:29 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CFE6081EF1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breen.xyz; s=sig1;
 t=1692471508; bh=UMz/uYWcXo9hHZMcRsWqJSlDA4r5PJDxFVOrZz7mVKU=;
 h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
 b=SGcs0BPDxenI72kx2OjC0SoVvldSNGQBl/9R913jfxJ1304B/y713Ni2xwh5QzY3M
 9S2uaO4BLZ29Vp/gpc9gYBpTzsrW0KHKbA3KDT8XcMcJdb6biArUsdhCE3eaHOz+ZT
 yiWEv+paO1AgctAbWPAClYoOpg9hTA1401JkVnuUuQzrGRTycDuvNYROa/yuEcOmgN
 uwX2zMSZQqo+G7HWPVo0UTJDctum7CmEyysqHuovVRk6a7io86FLfDajgGgApPrk8d
 sa+aFH0BCaGkf1kn6nlhr4cbYnvD6LButYXig5nzQzLM+T3EJCIrTYXe2DBSPEBzON
 cdbLbOCfbBv+A==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com
 [17.42.251.41])
 by st43p00im-ztbu10063601.me.com (Postfix) with ESMTPSA id 75C508C01A1;
 Sat, 19 Aug 2023 18:58:26 +0000 (UTC)
From: ryan@breen.xyz
Message-Id: <2BFA7EE8-2E0E-45A3-AC11-8E57F99EC775@breen.xyz>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Sat, 19 Aug 2023 14:58:15 -0400
In-Reply-To: <CAPv7TjZf4nLpCZPDOWK=vJGQuH0waTXkM6h40tc7G+YKAOGOGQ@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
References: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz>
 <CAPv7TjZf4nLpCZPDOWK=vJGQuH0waTXkM6h40tc7G+YKAOGOGQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
X-Proofpoint-ORIG-GUID: gTaK1JYy2A0-1-klAlmcRusdlntXFLU4
X-Proofpoint-GUID: gTaK1JYy2A0-1-klAlmcRusdlntXFLU4
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.591,18.0.572,17.11.176.26.0000000_definitions?=
 =?UTF-8?Q?=3D2023-07-31=5F02:2023-07-31=5F02,2020-02-14=5F11,2023-05-22?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 mlxlogscore=999
 clxscore=1030 suspectscore=0 mlxscore=0 adultscore=0 bulkscore=0
 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2308190183
X-Mailman-Approved-At: Mon, 21 Aug 2023 00:12:25 +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: Sat, 19 Aug 2023 18:58:32 -0000


--Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 for these attestations and subsequently reject the offending =
transactions. The 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-standing 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 =
collectively agree that if 75 of them issue an attestation indicating =
that a transaction violates sidechain withdrawal rules, then that =
transaction should be deemed 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 blocks are even associated with a sidechain.

> On Aug 19, 2023, at 10:35 AM, Ruben Somsen <rsomsen@gmail.com> wrote:
>=20
> Hi Ryan,
>=20
> 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".
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> 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
>=20
> In theory you can also do data availability sampling through the use =
of erasure codes, but that gets very complex and brittle.
>=20
> Hope this helps.
>=20
> Cheers,
> Ruben
>=20
> On Sat, Aug 19, 2023 at 4:29=E2=80=AFPM Ryan Breen via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto: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.
>>=20
>> 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
>>=20
>> Nevertheless, I will hit the high points of the concept here:
>>=20
>> The most challenging problem that BIP-300 aims to address is how to =
establish a two-way peg without involving a multisig federation and =
without 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.
>>=20
>> The method adopted by BIP-300 involves conducting sidechain =
withdrawals directly through the miners. To prevent miners from engaging =
in theft, the 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 are grouped into one large bundle per three month =
period.
>>=20
>> 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 =
the extent of automation. Nonetheless, I believe we now possess tools =
that can improve this process, leading to the concept of Sentinel =
chains.
>>=20
>> 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 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.
>>=20
>> 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 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.
>>=20
>> 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-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.
>>=20
>> In summary, drivechains:
>>=20
>> - 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
>>=20
>> Sentinel chains:
>>=20
>> - 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
>>=20
>> 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 fulfilling the long-awaited promise of a fully =
opt-in soft fork.
>>=20
>>=20
>> Ryan Breen
>> Twitter: ursuscamp
>> Email: ryan @ breen.xyz <http://breen.xyz/>
>> Web: https://ursus.camp <https://ursus.camp/>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;"><div><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 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 for these attestations and subsequently reject the offending =
transactions. The process doesn't involve the presentation of proof =
because it's a distributed trust =
relationship.</div><div><br></div><div>While Bitcoin full nodes could =
decide to operate their own sidechain nodes, we aim not to make this a =
requirement (addressing the long-standing 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 collectively agree =
that if 75 of them issue an attestation indicating that a transaction =
violates sidechain withdrawal rules, then that transaction should be =
deemed invalid by their node. Withdrawals are assumed valid if no public =
attestations are present.</div><div><br></div><div>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 blocks are =
even associated with a sidechain.</div><div><br><blockquote =
type=3D"cite"><div>On Aug 19, 2023, at 10:35 AM, Ruben Somsen =
&lt;rsomsen@gmail.com&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"ltr">Hi =
Ryan,<br><br>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".<br><br>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?<br><br>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.<br><br>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.<br><br>As a bit of history, fraud =
proofs were actually briefly considered for inclusion into segwit, but =
were abandoned due to the data availability 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/#update-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, =
though note I am currently of the opinion it's better used for =
low-bandwidth mainchain nodes instead of for sidechains): <a =
href=3D"https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13=
d1">https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</=
a><br><br>In theory you can 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-dev@lists.li=
nuxfoundation.org</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">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.camp/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/items/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 =
establish a two-way peg without involving a multisig federation and =
without 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.<br>
<br>
The method adopted by BIP-300 involves conducting sidechain withdrawals =
directly through the miners. To prevent miners from engaging in theft, =
the 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 are grouped into one large bundle per three month =
period.<br>
<br>
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 =
the extent of 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 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.<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 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.<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-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.<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 challenging 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 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 fulfilling the long-awaited 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"_blank">breen.xyz</a><br>
Web: <a href=3D"https://ursus.camp/" rel=3D"noreferrer" =
target=3D"_blank">https://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/mailman/listinfo/bitco=
in-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></body></html>=

--Apple-Mail=_DDEFEF4B-4917-4102-9B0E-203650F3A744--