diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2015-06-13 16:39:04 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-13 14:39:11 +0000 |
| commit | 2f6c57da6b76b96412de0f6c7cc645b439bd58b2 (patch) | |
| tree | 9b21263801c1cb11ab4e915741d393eb6d321c18 | |
| parent | 2824c30d822282fd290996b57a2fdde8d36bb713 (diff) | |
| download | pi-bitcoindev-2f6c57da6b76b96412de0f6c7cc645b439bd58b2.tar.gz pi-bitcoindev-2f6c57da6b76b96412de0f6c7cc645b439bd58b2.zip | |
Re: [Bitcoin-development] Scaling Bitcoin with Subchains
| -rw-r--r-- | 8d/ec657a1fccb00f7db45fc70d41b521079e6e4f | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/8d/ec657a1fccb00f7db45fc70d41b521079e6e4f b/8d/ec657a1fccb00f7db45fc70d41b521079e6e4f new file mode 100644 index 000000000..d64302d7c --- /dev/null +++ b/8d/ec657a1fccb00f7db45fc70d41b521079e6e4f @@ -0,0 +1,171 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pieter.wuille@gmail.com>) id 1Z3maV-0001Zq-41 + for bitcoin-development@lists.sourceforge.net; + Sat, 13 Jun 2015 14:39:11 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.160.169 as permitted sender) + client-ip=209.85.160.169; envelope-from=pieter.wuille@gmail.com; + helo=mail-yk0-f169.google.com; +Received: from mail-yk0-f169.google.com ([209.85.160.169]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Z3maT-0000yV-Vr + for bitcoin-development@lists.sourceforge.net; + Sat, 13 Jun 2015 14:39:11 +0000 +Received: by ykar6 with SMTP id r6so4149265yka.2 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 13 Jun 2015 07:39:04 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.129.131.214 with SMTP id t205mr24436888ywf.26.1434206344495; + Sat, 13 Jun 2015 07:39:04 -0700 (PDT) +Received: by 10.37.93.67 with HTTP; Sat, 13 Jun 2015 07:39:04 -0700 (PDT) +In-Reply-To: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com> +References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com> +Date: Sat, 13 Jun 2015 16:39:04 +0200 +Message-ID: <CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Andrew <onelineproof@gmail.com> +Content-Type: multipart/alternative; boundary=001a114f57c0b2c76c0518672fcc +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1Z3maT-0000yV-Vr +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sat, 13 Jun 2015 14:39:11 -0000 + +--001a114f57c0b2c76c0518672fcc +Content-Type: text/plain; charset=UTF-8 + +On Wed, May 20, 2015 at 4:55 AM, Andrew <onelineproof@gmail.com> wrote: + +> Hi +> +> I briefly mentioned something about this on the bitcoin-dev IRC room. In +> general, it seems experts (like sipa i.e. Pieter) are against using +> sidechains as a way of scaling. As I only have a high level understanding +> of the Bitcoin protocol, I cannot be sure if what I want to do is actually +> defined as a side chain, but let me just propose it, and please let me know +> whether it can work, and if not why not (I'm not scared of digging into +> more technical resources in order to fully understand). I do have a good +> academic/practical background for Bitcoin, and I'm ready to contribute code +> if needed (one of my contributions includes a paper wallet creator written +> in C). +> +> +In your proposal, transactions go to a chain based the addresses involved. +We can reasonably assume that different people's wallet will tend to be +distributed uniformly over several sidechains to hold their transactions +(if they're not, there is no scaling benefit anyway...). That means that +for an average transaction, you will need a cross-chain transfer in order +to get the money to the recipient (as their wallet will usually be +associated to a chain that is different from your own). Either you use an +atomic swap (which actually means you end up briefly with coins in the +destination chain, and require multiple transactions and a medium delay), +or you use the 2way peg transfer mechanism (which is very slow, and reduces +the security the recipient has to SPV). + +Whatever you do, the result will be that most transactions are: +* Slower (a bit, or a lot, depending on what mechanism you use). +* More complex, with more failure modes. +* Require more and larger transactions (causing a total net extra load on +all verifiers together). + +And either: +* Less secure (because you rely on a third party to do an atomic swap with, +or because of the 2 way peg transfer mechanism which has SPV security) +* Doesn't offer any scaling benefit (because the recipient needs to fully +validate both his own and the receiver chain). + +In short, you have not added any scaling at all, or reduced the security of +the system significantly, as well as made it significantly less convenient +to use. + +So no, sidechains are not a direct means for solving any of the scaling +problems Bitcoin has. What they offer is a mechanism for easier +experimentation, so that new technology can be built and tested without +needing to introduce a new currency first (with the related speculative and +network effect problems). That experimentation could eventually lead us to +discover mechanisms for better scaling, or for more scalability/security +tradeoffs (see for example the Witness Segregation that Elements Alpha has). + +-- +Pieter + +--001a114f57c0b2c76c0518672fcc +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">On Wed, May 20, 2015 at 4:55 AM, Andrew <span dir=3D"ltr">= +<<a href=3D"mailto:onelineproof@gmail.com" target=3D"_blank">onelineproo= +f@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class= +=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= +ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>= +<div><div><div><div><div><div>Hi<br><br></div>I briefly mentioned something= + about this on the bitcoin-dev IRC room. In general, it seems experts (like= + sipa i.e. Pieter) are against using sidechains as a way of scaling. As I o= +nly have a high level understanding of the Bitcoin protocol, I cannot be su= +re if what I want to do is actually defined as a side chain, but let me jus= +t propose it, and please let me know whether it can work, and if not why no= +t (I'm not scared of digging into more technical resources in order to = +fully understand). I do have a good academic/practical background for Bitco= +in, and I'm ready to contribute code if needed (one of my contributions= + includes a paper wallet creator written in C).<br><br></div></div></div></= +div></div></div></div></div></blockquote><div><br></div><div>In your propos= +al, transactions go to a chain based the addresses involved. We can reasona= +bly assume that different people's wallet will tend to be distributed u= +niformly over several sidechains to hold their transactions (if they're= + not, there is no scaling benefit anyway...). That means that for an averag= +e transaction, you will need a cross-chain transfer in order to get the mon= +ey to the recipient (as their wallet will usually be associated to a chain = +that is different from your own). Either you use an atomic swap (which actu= +ally means you end up briefly with coins in the destination chain, and requ= +ire multiple transactions and a medium delay), or you use the 2way peg tran= +sfer mechanism (which is very slow, and reduces the security the recipient = +has to SPV).<br><br></div><div>Whatever you do, the result will be that mos= +t transactions are:<br></div><div>* Slower (a bit, or a lot, depending on w= +hat mechanism you use).<br></div><div>* More complex, with more failure mod= +es.<br></div><div>* Require more and larger transactions (causing a total n= +et extra load on all verifiers together).<br></div><div><br></div><div>And = +either:<br></div><div>* Less secure (because you rely on a third party to d= +o an atomic swap with, or because of the 2 way peg transfer mechanism which= + has SPV security)<br></div><div>* Doesn't offer any scaling benefit (b= +ecause the recipient needs to fully validate both his own and the receiver = +chain).<br><br></div><div>In short, you have not added any scaling at all, = +or reduced the security of the system significantly, as well as made it sig= +nificantly less convenient to use.<br><br></div><div>So no, sidechains are = +not a direct means for solving any of the scaling problems Bitcoin has. Wha= +t they offer is a mechanism for easier experimentation, so that new technol= +ogy can be built and tested without needing to introduce a new currency fir= +st (with the related speculative and network effect problems). That experim= +entation could eventually lead us to discover mechanisms for better scaling= +, or for more scalability/security tradeoffs (see for example the Witness S= +egregation that Elements Alpha has).<br><br></div><div>-- <br></div><div>Pi= +eter<br><br></div></div></div></div> + +--001a114f57c0b2c76c0518672fcc-- + + |