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 F3E9CA82 for ; Tue, 11 Jul 2017 20:36:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F1FCCE for ; Tue, 11 Jul 2017 20:36:35 +0000 (UTC) Received: by mail-qt0-f171.google.com with SMTP id b40so3253506qtb.2 for ; Tue, 11 Jul 2017 13:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=A7cGXP4jutQ3Q1Ojk/8/aVNb+bQwckzQwgTYP4bnc9A=; b=FkBl0YUryW/CjBNWwlP+tzDPvFgmB0coWRLcJTO3PbEOw/YnE7rJcKLusQxoLNbPiG E9ceQ77O3jstV6BU+rLNaffVuyIYZwcjHQIclxzNGHAEXTBio2A3xevQ0Dd+DxfRxuEA Wdjybbz9Q9NGY563r1C6ZOx3JYzNsqUyFUNKU7UJnYScd729FzFlysf9AtrXMf1iwjEX 6oKiNCD081yhXKxF3KEpO91jjtcPr/KgPhI+jfQ0Uy99kmRShGWwmTip1cUn2iBKm3KS 8zDiClXQis2tgaSJxAq8dTu1MzrydIdifaVKTS8nOI6QWmpzZmAKe56n4vMtChU2lzLH qHFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=A7cGXP4jutQ3Q1Ojk/8/aVNb+bQwckzQwgTYP4bnc9A=; b=i/5JFQFHNu/d46KqCZQoEuz8kqerw34ht+ZuH66YgBgriSqceZ4IjcJ41RFzVWZWR7 PV8inbhFR1kZYedWqtMEEXbdV0A0HJKU1hjQzB7gycdywAUbJo4dvAuuR9t3u7hLc9ZS zM4YhZa/2JC7CJ4PaFiqQtXt3iMFwC5giMozZMtYacUxzSV4LXN1NkUV/pLNPAfPmjJ4 3zR283Aqxe+jTz/Tu3CaVzvNMHb7pPsoBMt1mjd3IiNSKS8lYgGT/nM0/lb1op/SzPyF VpiuGcSFNlPbhWFkC4tMxsxF+vP/V+1hU0s1pPhkdruRECIUkzxSVjiMM/2t6Sz4bT9p xCIg== X-Gm-Message-State: AIVw113up7hKzJCyGEeWl/ppq8/RC3VOCl7S1nZCnrKlQ1Qeg4OCqJci kvrzbJWz+BzVFFxS X-Received: by 10.200.14.12 with SMTP id a12mr2357281qti.115.1499805393992; Tue, 11 Jul 2017 13:36:33 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id s12sm265969qtc.52.2017.07.11.13.36.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:36:33 -0700 (PDT) To: Pieter Wuille , Chris Stewart , Bitcoin Dev References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> From: Paul Sztorc Message-ID: Date: Tue, 11 Jul 2017 16:36:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3942536F8EE65F365D786F97" Content-Language: en-US X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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:09:45 +0000 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 20:36:36 -0000 This is a multi-part message in MIME format. --------------3942536F8EE65F365D786F97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. 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". The only true difference is the "extra risk of miners being able to vote to steal your money", but as I have pointed out on this mailing list several times, I do not actually believe that there is any marginal risk -- miners can already "vote to steal your money" in the double-spend and ln-channel-theft contexts. I have also argued that the "risk" is actually desirable in an opt-in context, because it puts the burden of proof on miners/developers (to convince users that they should move over to the sidechain). 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 a= ll. Paul On 7/11/2017 4:01 PM, Pieter Wuille wrote: > On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" > > wrote: > > Concept ACK. > > If drivechains are successful they should be viewed as the way we > scale > > > I strongly disagree with that statement. > > Drivechains, and several earlier sidechains ideas, are not a > scalability improvement, but merely enabling users to opt-in for > another security model. > > While obviously any future with wider adoption will need different > technologies that have different trade-offs, and anyone is free to > choose their security model, I don't think this particular one is > interesting. In terms of validation cost to auditors, it is as bad as > just a capacity increase on chain, while simultaneously adding the > extra risk of miners being able to vote to steal your money. > > Cheers, > > --=20 > Pieter > --------------3942536F8EE65F365D786F97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.

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".

The only true difference is the "extra risk of miners being able to vote to steal your money", but as I have pointed out on this mailing list several times, I do not actually believe that there is any marginal risk -- miners can already "vote to steal your money" in the double-spend and ln-channel-theft contexts. I have also argued that the "risk" is actually desirable in an opt-in context, because it puts the burden of proof on miners/developers (to convince users that they should move over to the sidechain). 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.

Paul


On 7/11/2017 4:01 PM, Pieter Wuille wrote:
On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Concept ACK.

If drivechains are successful they should be viewed as the way we scale

I strongly disagree with that statement.

Drivechains, and several earlier sidechains ideas, are not a scalability improvement, but merely enabling users to opt-in for another security model.

While obviously any future with wider adoption will need different technologies that have different trade-offs, and anyone is free to choose their security model, I don't think this particular one is interesting. In terms of validation cost to auditors, it is as bad as just a capacity increase on chain, while simultaneously adding the extra risk of miners being able to vote to steal your money.

Cheers,

--
Pieter


--------------3942536F8EE65F365D786F97--