From: Paul Sztorc <truthcoin@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Sidechains pre-BIP Discussion
Date: Wed, 20 Apr 2016 11:56:57 -0400 [thread overview]
Message-ID: <5717A6C9.1030702@gmail.com> (raw)
Dear list,
This message concerns pegged "sidechains", namely the Two Way Peg [1].
Specifically, it is to introduce a new OP Code (perhaps called
"OP_CheckVotesVerify"). This OP code can be deployed by soft fork, and
has (as we all probably know) many benefits, including:
1. ("Optional hard forks") Sidechains allow 'opt in' adoption of new
features. As a result, Bitcoin (the bearer asset, not the software) will
never need to worry about competing with an alternate system. This
includes competitors such as Ripple or Ethereum (supposedly
"innovative"), as well as BitcoinXT and Bitcoin Classic (supposedly
"popular").
2. ("Staging Upgrades") SCs allow complex updates to Bitcoin to be
tested, in a realistic environment (where actual BTC are at risk, and
utilizing actual network mining resources). If these updates fail, they
can be revised; if they succeed, they can be incorporated into the
mainchain.
3. Directing "blockchain resources" to Bitcoin. This includes money,
developer talent, public attention, etc.
4. Less time spent debating controversial features. Instead, we return
to a culture of "permissionless innovation".
Again, as we all know, the concept has generally received high interest
and favorable appraisal.
--
However, this feature has highly complex effects on the Bitcoin
ecosystem, and so the details should command our full attention.
First, the deployment of this OP Code involves new block validation
rules ("Drivechain") which are described on my blog [2].
In addition to that post, I intend to release short presentations:
1. On the overall design justification.
2. On "Enforcing Limits on Shared Resources". This explores the
potential for SCs to have a detrimental effect on users of vanilla BTC,
and how this proposal confronts these problems.
3. On the governance of SCs-- aka the degree of 'coupling',
inter-relatedness, and/or hierarchy --- and how Drivechain's design acts
to maximize the total value of the "chain portfolio".
My purpose, in emailing today, is to begin the conversation. The scope
of the concept is simply too large, to draft a readable BIP without
knowing what the actual points of interest are. Please express your
reactions!
Thank you for reading,
Paul
P.S. In assessing the proposal, you may find a recent technical paper
[3] by Sergio Demian Lerner to be of interest.
--
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004724.html
[2] http://www.truthcoin.info/blog/drivechain/
[3] http://www.rootstock.io/#resources (
https://uploads.strikinglycdn.com/files/27311e59-0832-49b5-ab0e-2b0a73899561/Drivechains_Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf
)
reply other threads:[~2016-04-20 15:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=5717A6C9.1030702@gmail.com \
--to=truthcoin@gmail$(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