To: Pieter Wuille <pieter.wuille@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>
	<CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <93a5f7e8-08ee-06a8-f638-b4e85814d598@gmail.com>
Date: Tue, 11 Jul 2017 18:49:19 -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: <CAPg+sBjhKON4Mmg06pgpBgfp5xWT2b7xgoWwybsWbbuF9CNt_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
Precedence: list

On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin@gmail.com> wrot=
e:
>> 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.
I'm sure you did not intend to do so, of course.

>> You went on to "disagree", but every point of contention you introduce=
d was
>> something that would apply to both drivechain-sourced capacity and
>> hardfork-sourced capacity. Neither improves scalability, and both allo=
w
>> 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 "validatio=
n 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.
I think I understand what you are saying, but in this case "it" [your
experience] isn't a different security model *for you*. Perhaps we
disagree on the significance of this qualification.

It seems to be me that your position puts you in danger of having to go
out and protect users from investing in insecure _Altcoins_. Probably,
in a world where altcoins were magically impossible, there would be an
even greater demand for Bitcoin capacity than there is in our
Altcoin-filled world (for a few reasons).

> 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.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.

However, though I think your logic is correct in general, I think in
this specific instance it would be somewhat unreasonable to ignore the
fact that, today, we have clear evidence that many people *are* in fact
chomping at the bit to literally leave this blockchain for one that is
almost identical save for a larger maxblocksize.


>> 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 improve=
ment
>> (at least, by any epistemological standard that I can think of). If yo=
u have
>> new objections to these claims, I'm sure we would all benefit from hea=
ring
>> 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.
Again, I think you may be right. However, users may be similarly misled
in the case of Altcoins (or in the case of investments in fiat
currency), and they may be misled in their use of all kinds of
cryptographic software, and in the clothes that they buy and all of
their other activities.

I would strongly support clear expectations, and constant reminders to
users that the security models are different. Perhaps, even, annoying
dialogue boxes that pop up when/if a user tries to move their funds to a
sidechain.

But, again, this (I think) is something that would *also* apply to a
hard fork. We cannot know if Pieter Wuille, for example, believes that a
given hard fork is "push[ing] users beyond what is reasonable" until we
ask him.

--Paul