From: ryan@breen•xyz
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
Date: Tue, 15 Aug 2023 22:02:38 -0400 [thread overview]
Message-ID: <E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz> (raw)
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
next reply other threads:[~2023-08-16 2:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 2:02 ryan [this message]
2023-08-19 14:35 ` Ruben Somsen
2023-08-19 18:58 ` ryan
2023-08-21 22:32 ` Ruben Somsen
2023-08-28 13:48 ` ZmnSCPxj
2023-08-28 14:35 ` ryan
2023-08-30 11:05 ` ZmnSCPxj
2023-08-31 0:16 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E4A37B75-349D-4CD8-B8E2-9686EFDA9EEA@breen.xyz \
--to=ryan@breen$(echo .)xyz \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox