summaryrefslogtreecommitdiff
path: root/eb/e1f27dcd62f3826e44a6631853605bb93be95e
blob: 46842cd41af794101ec6af175f50553b232835e9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
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--