From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ryan@breen•xyz
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
Date: Thu, 31 Aug 2023 00:16:25 +0000 [thread overview]
Message-ID: <1vNs5QDY6fY_t7bjbY_4gSaYHv0xxDuSkN3eFbW_qM8Q_1-Iwcf3u2AkG7JTQQ__9RxbnhDAI0A5TisV6e1pv_i4hDcj9AVKJZSnLxWu66E=@protonmail.com> (raw)
In-Reply-To: <E9WH5C46HJT_uwLTnliTeZSZPrPwoKQs57muUxPVzaGWCWWriC4m2HGVoagR8dfvRBU_1qGtvlhojqIf_854em3_bJIR6DzAqAGHR6fW_nI=@protonmail.com>
Good morning Ryan, et al.,
My long-ago interest in sidechains was the hope that they would be a scaling solution.
However, at some point I thought "the problem is that blockchains cannot scale, sidechains means MORE blockchains that cannot scale, what was I thinking???"
This is why I turned my attention to Lightning, which is a non-blockchain mechanism for scaling blockchains.
The only other reason for sidechains is to develop new features.
However, any actually useful features should at some point get onto the "real" Bitcoin.
In that case, a sidechain would "only" be useful as a proof-of-concept.
And in that case, a federated sidechain among people who can slap the back of the heads of each other in case of bad behavior would be sufficient to develop and prototype a feature.
--
In any case, if you want to consider a "user-activated" sidechain feature, you may be interested in an old idea, "mainstake", by some obscure random with an unpronouncable name: https://zmnscpxj.github.io/sidechain/mainstake/index.html
Here are some differences compared to e.g. drivechains:
* Mainchain miners cannot select the builder of the next sidechain block, without increasing their required work (possibly dropping them below profitability).
More specifically:
* If they want to select a minority (< 50%) sidechain block builder, then their difficulty increases by at least one additional bit.
The number of bits added is basically the negative log2 of the share of the sidechain block builder they want to select.
* The intent is to make it very much more unpalatable for a sidechain block builder to pay fees to the mainchain miner to get its version of the sidechain block confirmed.
A minority sidechain block builder that wants to lie to the mainchain about a withdrawal will find that the fees necessary to convince a miner to select them are much higher than the total fees of a block.
This better isolates sidechain conflicts away from mainchain miners.
* Miners can censor the addition of new mainstakes or the renewal of existing mainstakes.
However, the same argument of censorship-resistance should still apply here (< 51% cannot reliably censor, and >=51% *can* censor but that creates an increasing feerate for censored transactions that encourages other potential miners to evict the censor).
* In particular, miners cannot censor sidechain blocks easily (part of the isolation above), though they *can* censor new mainstakers that are attempting to evict mainstakers that are hostile to a sidechain.
There are still some similarities.
Essentially, all sidechain funds are custodied by a set of anonymous people.
One can consider as well that fund distribution is unlikely to be well-distributed, and thus it is possible that a small number of very large whales can simply take over some sidechain with small mainstakers and outright steal the funds in it, making them even richer.
(Consider how the linked write-up mentions "PoW change" much, much too often, I am embarassed for this foolish pseudonymous writer)
Regards,
ZmnSCPxj
prev parent reply other threads:[~2023-08-31 0:17 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
2023-08-30 11:05 ` ZmnSCPxj
2023-08-31 0:16 ` ZmnSCPxj [this message]
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='1vNs5QDY6fY_t7bjbY_4gSaYHv0xxDuSkN3eFbW_qM8Q_1-Iwcf3u2AkG7JTQQ__9RxbnhDAI0A5TisV6e1pv_i4hDcj9AVKJZSnLxWu66E=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=ryan@breen$(echo .)xyz \
/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