From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Patrick Sharp <psharp.x13@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] idea post: bitcoin side chain implementation
Date: Mon, 25 Sep 2017 20:35:39 -0400 [thread overview]
Message-ID: <7lMVV5tc0S5aSzZV8305yOhRd8AWufZhxToS31hmq6SGpiMC2eLZsvHYcsyj_HzFo6ip5p6CtKXRiHxxRVM3IHsCnm8qXWJT_iheDM3HYZU=@protonmail.com> (raw)
In-Reply-To: <CAES+R-pHkDHSPpTcyJyEv2rSWOvAkG+zUqs8hPwbHigejyFvDw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
Good morning Patrick,
>Non official chains suffer from the fact that few if any miners are going to mine them so they lack security on par with the main chain.
That is why most sidechain proposals use some kind of merge mining, where a commitment to another chain's block is published on the Bitcoin chain. Drivechain has "blind" merge mining, my recent "mainstake" proposal publishses entire sidechain block headers on the mainchain. These techniques provide security that is nearer to mainchain security.
>And more over most
>users aren't going to use them because its not magic.
No technology is magic, so I do not understand this sentence.
>If my ultimate goal is official side chains that include part of the reward such security is at parity between all chains and that the official software
>automatically enable users to distribute their burden, would my course of action be to build an external proof-of-concept side chain of side chains?
>or do you doubt that official reward splitting chains will ever find their way into bitcoin core?
I think it would be better to term your system as "sharding" rather than "sidechain".
If and when we are able to actually agree upon some kind of sidechain-enabling proposal that is acceptable to the majority of Bitcoin Core developers, then yes, you should make a sidechain that is capable of sharding. Sharding a distributed ledger while ensuring correct operation is a hard problem; in particular it is almost impossible to protect against double-spending unless you can see all officially-added-to-the-chain transactions.
See: https://petertodd.org/2015/why-scaling-bitcoin-with-sharding-is-very-hard
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 2142 bytes --]
next prev parent reply other threads:[~2017-09-26 0:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 21:53 Patrick Sharp
2017-09-25 22:58 ` CryptAxe
2017-09-26 0:07 ` Patrick Sharp
2017-09-26 0:35 ` ZmnSCPxj [this message]
2017-09-26 1:15 ` Patrick Sharp
2017-09-26 0:01 ` 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='7lMVV5tc0S5aSzZV8305yOhRd8AWufZhxToS31hmq6SGpiMC2eLZsvHYcsyj_HzFo6ip5p6CtKXRiHxxRVM3IHsCnm8qXWJT_iheDM3HYZU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=psharp.x13@gmail$(echo .)com \
/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