To: =?UTF-8?Q?Hampus_Sj=c3=b6berg?= <hampus.sjoberg@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
	<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
	<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
	<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
	<CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <dd7bc896-e9f5-c8a2-aaf2-cdcfad43b44c@gmail.com>
Date: Thu, 13 Jul 2017 13:04:01 -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: <CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
Precedence: list

Hello,


On 7/13/2017 9:17 AM, Hampus Sj=C3=B6berg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.

Correct.


> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.


You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).

In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].

I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.

[1] https://en.bitcoin.it/wiki/Value_overflow_incident


> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...

Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in betwee=
n.


> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.

Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.

I'm not really sure the extent to which that "counts" as increasing
capacity.

Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".

Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with=
-scaling


> Thanks for all your work so far Paul.

You're welcome!

Paul