From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3808BA91 for ; 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 ; Tue, 11 Jul 2017 21:40:38 +0000 (UTC) Received: by mail-wr0-f176.google.com with SMTP id r103so7209440wrb.0 for ; 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: References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> From: Pieter Wuille Date: Tue, 11 Jul 2017 14:40:36 -0700 Message-ID: To: Paul Sztorc 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:40:39 -0000 On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc 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