public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ryan@breen•xyz
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
Date: Mon, 28 Aug 2023 10:35:30 -0400	[thread overview]
Message-ID: <0D44C322-E2B4-4F80-A5D8-7D8304BDAE1A@breen.xyz> (raw)
In-Reply-To: <2FylpMx7IsZBt3ILxEt9pVB0Kq03jZqTUeLnB2hWT5j8qiB4o6plW3gjhBXQ_7p4MwQ_npQUpZ64hQaR6UnLhMNCnk_jCv1XObmrJbjrVqg=@protonmail.com>

I appreciate your questions, ZmnSCPxj.

I will answer your second question first: Mainchain nodes do not ever validate sidechain blocks. Sidechain nodes watch Bitcoin for invalid withdrawals, and publish signed attestations to a public broadcast network (such as Nostr) that a transaction is making an invalid withdrawal. These sidechain nodes are the so-called sentinels.

Bitcoin full nodes wishing to participate in holding miners accountable for stealing will watch the public broadcast network for attestations of improper withdrawals and treat those transactions as de facto invalid, thus forking violating miners off the network. In this way, launching a Sentinel chain mimics a user-activated soft fork, but without any changes to Bitcoin Core consensus logic.

Bitcoin full nodes would choose their own limited set of sidechain validators to trust. They might run their own sidechain node and trust that result exclusively. They might instead choose to trust a set of high quality community members such as companies, etc.

A downside to this method are the same as the difficulties of launching a soft fork. Making sure enough nodes (or miners) are on board to enforce the new rules prior to launch of a sidechain, or a minority of users will fork off the network. Additionally, maintaining a healthy network of sentinels for a sidechain is an additional angle to consider. 

The upside of this method is that sidechains can be user-activated, not just miner-activated like under the BIP-300 framework. And it allows Bitcoin full nodes to hold miners accountable for obeying the sidechain withdrawal rules.

--------------------

To answer your first question: When you say the sentinel chain software, are you asking what would happen if the sidechain developers create malicious code in sidechain node software? I suppose that would depend on the upgrade process of the sidechain, but the maximum fallout from malicious Sentinel chains is the exact same as any other sidechain proposal: the sidechain users get rugged.

The concept behind Sentinel chains puts no restriction on how sentinel chains may operate, only how the “difficult” part of launching a 2WP sidechain, peg-outs from sidechain to mainchain, may work without advanced cryptographic techniques such a ZKPs.

Thanks,
Ryan (ursuscamp on twitter)

> On Aug 28, 2023, at 9:48 AM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> 
> Good morning Ryan,
> 
> If I modify your Sentinel Chain open-source software so that it is honest for 999 sidechain blocks, then lies and says that the 1000th block is invalid even though it actually is, what happens?
> 
> Do mainchain nodes need to download the previous 999 sidechain blocks, run the sidechain rules on them, and then validate the 1000th sidechain block itself?
> 
> Regards,
> ZmnSCPxj



  reply	other threads:[~2023-08-28 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16  2:02 ryan
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 [this message]
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=0D44C322-E2B4-4F80-A5D8-7D8304BDAE1A@breen.xyz \
    --to=ryan@breen$(echo .)xyz \
    --cc=ZmnSCPxj@protonmail$(echo .)com \
    --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