From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A0DAC0032 for ; 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 ; 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 ; 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 ; 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 ; 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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