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
|
Return-Path: <ryan@breen.xyz>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6A0DAC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 02:12:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 41DEC82150
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 02:12:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 41DEC82150
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=g/5kPiKv
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 2.001
X-Spam-Level: **
X-Spam-Status: No, score=2.001 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
FROM_SUSPICIOUS_NTLD_FP=0.402, 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 ewXHvjEX0_5s
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 02:12:13 +0000 (UTC)
X-Greylist: delayed 561 seconds by postgrey-1.37 at util1.osuosl.org;
Wed, 16 Aug 2023 02:12:12 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E4DD88214E
Received: from st43p00im-zteg10072001.me.com (st43p00im-zteg10072001.me.com
[17.58.63.167])
by smtp1.osuosl.org (Postfix) with ESMTPS id E4DD88214E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 02:12:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breen.xyz; s=sig1;
t=1692151370; bh=U6shEkXSqkf2rJNi6Dd6l5fBbT/vmhgZgWOnIIVDcLw=;
h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To;
b=g/5kPiKvXq+3cz4BOfotTLIzCZBIel4Zn65+gTTf1qoFI8svLM+vqJrl8XkAFG/n2
qi4RqBzjuSO6KXdjus6xtqEeo2xRy2jO68w1NkrY+cicntrB5GJnw9mN9MsHHBjYuo
sr1OorXIsTK6XM36lXjywJDJeVctyvszhCapll3oXKc7cKks6uo20u9Akmx8ZNB1t0
nDM7PFT/i/KeqUAXgWEVXnSuj3sXtsXLFiAXBVDXNqBhBYX9lm174Z6x49p2HTgC/Y
YH95vB7vIQ0OsvkQOCT1ixCE8RfU8/o2vd/7Al5kD3GejwEwF0dxyy66ou0JGJIDPC
ro/2pwHAGUuvw==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com
[17.42.251.41])
by st43p00im-zteg10072001.me.com (Postfix) with ESMTPSA id EE53BB400CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 02:02:49 +0000 (UTC)
From: ryan@breen.xyz
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Message-Id: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz>
Date: Tue, 15 Aug 2023 22:02:38 -0400
To: bitcoin-dev@lists.linuxfoundation.org
X-Mailer: Apple Mail (2.3731.700.6)
X-Proofpoint-GUID: O7aHc7sANSuHoIpgSibKiQLfPoCrRXUP
X-Proofpoint-ORIG-GUID: O7aHc7sANSuHoIpgSibKiQLfPoCrRXUP
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 clxscore=1030
bulkscore=0
suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=835 malwarescore=0
mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.12.0-2212070000 definitions=main-2308160017
X-Mailman-Approved-At: Sat, 19 Aug 2023 14:29:10 +0000
Subject: [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: Wed, 16 Aug 2023 02:12:14 -0000
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/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 =
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.
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.
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.
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.
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.
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.
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 fulfilling the long-awaited promise of a fully =
opt-in soft fork.
Ryan Breen
Twitter: ursuscamp
Email: ryan @ breen.xyz
Web: https://ursus.camp
|
