diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2017-07-11 14:40:36 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-07-11 21:40:39 +0000 |
| commit | 11ccbfe7e83a0202970badbddc3603bae598d73b (patch) | |
| tree | 78f5f81f0535afcf1bac1722520056e944734128 /3d | |
| parent | 28e079fdc81ea891f8617c252802b5d7854128c4 (diff) | |
| download | pi-bitcoindev-11ccbfe7e83a0202970badbddc3603bae598d73b.tar.gz pi-bitcoindev-11ccbfe7e83a0202970badbddc3603bae598d73b.zip | |
Re: [bitcoin-dev] Updating the Scaling Roadmap
Diffstat (limited to '3d')
| -rw-r--r-- | 3d/9f7ff34d6f0aa5a6dd8db13ecbee7e41e22892 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/3d/9f7ff34d6f0aa5a6dd8db13ecbee7e41e22892 b/3d/9f7ff34d6f0aa5a6dd8db13ecbee7e41e22892 new file mode 100644 index 000000000..5f2955aa4 --- /dev/null +++ b/3d/9f7ff34d6f0aa5a6dd8db13ecbee7e41e22892 @@ -0,0 +1,129 @@ +Return-Path: <pieter.wuille@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3808BA91 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Jul 2017 21:40:39 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com + [209.85.128.176]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1BAAAC + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Jul 2017 21:40:38 +0000 (UTC) +Received: by mail-wr0-f176.google.com with SMTP id r103so7209440wrb.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 11 Jul 2017 14:40:38 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc; bh=aa+dKLcjRIDcHYdu8jbwMn5KoBuYqQG3mnBh9mWes04=; + b=atEZzp2gOlntJFHLaT6+PVfH3CEjl5vMebTlQNM7XdWK1W/L7a0SAWrlHDB14zi+mL + N4E9cbL8herMn61QJCXURPrRXKDWvF/nMdneBd55lOTHDaHMI5E40/FGWb5afSbCJLNK + wG8cuFuVKuEdfLFAQ4uyWrNAKbbvoJ+4F/9Aqo6LBOPnopsX+lvETumAM3c0NQmyP2HD + MIoJYSc2xk5KdfTqX3Euap4hvh+kPwZkBF6FzIbcsrpvFyQifsxmhzVIrEZEhVmHOkJP + QWC2qbyYzg4cuwbBeUhJiWmWE3gFHcNCGdlUN1xsjCggnvIe7IpnOPpNTx06KT6t2FBY + Sqlg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:cc; + bh=aa+dKLcjRIDcHYdu8jbwMn5KoBuYqQG3mnBh9mWes04=; + b=f6Ivm7BHKx8Z+LFPnWzcjnrnsJKG7BnZzNBfYMPQ/r3YvnwJF5cYuvLhqTxLCQyC5w + 9ATNb5apJhpW5rDFmR+LAZNVlVfPOyYI1tGn4XCQ7vifzq2RpLxXJJTn/NFjIbULpHAO + yyGFb8vQSlyiQND7F3Gl5g5Njm647AVC6GoXsIMqw1+HEM1Tc9nAs8yC/ipiGH5cyFu6 + uPXFFsuvg1zQoTN15hTKx3EGQq5g4d0uHk7XslunI/GKf8FPw48M6qxRXgsZJvshMirD + yjxNQ1K0/rdFGghEHeSK7kawNPfS6e6+ZjxwSt/j8fknGvc0BdKiifrC5ThpJySDgpiw + idzQ== +X-Gm-Message-State: AIVw112JIz29vRtt4R29esCCpuD36MmOFdDVGE+WBtjU8B7I7ipaxnU5 + xp2PPJoOYqry2DePUaqaH46W0UrJ2w== +X-Received: by 10.80.181.80 with SMTP id z16mr3910738edd.6.1499809237234; Tue, + 11 Jul 2017 14:40:37 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.80.222.141 with HTTP; Tue, 11 Jul 2017 14:40:36 -0700 (PDT) +In-Reply-To: <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com> +References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> + <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com> + <CAPg+sBghOOcyRqtuAXhWQ=yA1nuqw8Xs+yrK9CTpRo4uc3773Q@mail.gmail.com> + <d53dc5d2-b761-53c3-3bb8-0d8d39cbda37@gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +Date: Tue, 11 Jul 2017 14:40:36 -0700 +Message-ID: <CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com> +To: Paul Sztorc <truthcoin@gmail.com> +Content-Type: text/plain; charset="UTF-8" +X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, + RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 11 Jul 2017 21:54:15 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 11 Jul 2017 21:40:39 -0000 + +On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin@gmail.com> wrote: +> Pieter, +> +> I think that you have misrepresented Chris' view by taking it out of +> context. His complete quote reads "If drivechains are successful they should +> be viewed as the way we scale -- not hard forking the protocol." Chris is +> comparing Drivechains/sidechains to a hard fork. + +I apologize here; I didn't mean to misrepresent his viewpoint. + +> You went on to "disagree", but every point of contention you introduced was +> something that would apply to both drivechain-sourced capacity and +> hardfork-sourced capacity. Neither improves scalability, and both allow +> users only the opportunity to select a different security model. If I +> understand you, the point at which a security model does not become +> "interesting" to you, would be the exact same point in the drivechain and +> hardfork worlds. Both, at any rate, have the same effect on "validation cost +> to auditors". + +If you're talking about the extreme case where every full node in the +increased capacity single chain model corresponds to a node that +validates both chains and all transfers between them in the +drivechains, I agree. At that point they become nearly equivalent in +terms of ease of adoption, resource costs, and capacity. + +However, I don't think that is a realistic expectation. When +considering drivechains as a capacity increase, I believe most people +think about a situation where there are many chains that give an +increased capacity combined, but not everyone verifies all of them. +This is what I meant with uninteresting security model, as it requires +increased miner trust for preventing the other chains' coins from +being illegally transferred to the chain you're operating on. + +Regardless, people are free experiment and adopt such an approach. The +nice thing about it not being a hardfork is that it does not require +network-wide consensus to deploy. However, I don't think they offer a +security model that should be encouraged, and thus doesn't have a +place on a roadmap. + +> Since their sidechain coins cannot appreciate in value relative +> to the mainchain coins, users would only opt-in if they felt that they were +> sufficiently compensated for any and all risks. Hence, it is difficult to +> list this item as a drawback when, to the user, it is a strict improvement +> (at least, by any epistemological standard that I can think of). If you have +> new objections to these claims, I'm sure we would all benefit from hearing +> them, myself most of all. + +Am I right in summarizing your point here as "This approach cannot +hurt, because if it were insecure, people can choose to not use it."? +I'm not sure I agree with that, as network effects or misinformation +may push users beyond what is reasonable. + +Cheers, + +-- +Pieter + |