path: root/06/6df0a4e156980ad6ae70c79262385fb468a8a3

Return-Path: <contact@taoeffect.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 38B48BC9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Jun 2017 21:30:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a62.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3A519E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Jun 2017 21:30:52 +0000 (UTC)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 5E86263406F;
	Sun, 18 Jun 2017 14:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=
	content-type:mime-version:subject:from:in-reply-to:date:cc
	:message-id:references:to; s=taoeffect.com; bh=pbjE9AE1LV+RcgBMP
	/lIP2A+A+Y=; b=nmHuOThpG54SeqTKhmkLxnzV5otY2EFriCQk2pkOUfuLgf8F9
	YaSTgD6EH3ovWXuHleCO6Ys5APyrKxaNvNeOrbRSdWuIxMi1tPLOyiphyOmBFKwt
	Vv39DqksAwHKAhug3Q3YClGlIAOYxCCtHk5yXIvs4Kulrh7g3TDv65o7WQ=
Received: from [192.168.42.64] (184-23-252-118.fiber.dynamic.sonic.net
	[184.23.252.118])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: contact@taoeffect.com)
	by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 2717D63406E; 
	Sun, 18 Jun 2017 14:30:51 -0700 (PDT)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_70A07552-0125-4749-8C1D-25D8A3F086CE";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
Date: Sun, 18 Jun 2017 14:30:51 -0700
X-Mao-Original-Outgoing-Id: 519514251.018555-e41691d6997c7ee5678b830d8bff61e7
Message-Id: <AAC86547-7904-4475-9966-138130019567@taoeffect.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 18 Jun 2017 21:39:21 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
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: Sun, 18 Jun 2017 21:30:55 -0000


--Apple-Mail=_70A07552-0125-4749-8C1D-25D8A3F086CE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B717153B-DA6E-491E-8CAF-6F3899717619"


--Apple-Mail=_B717153B-DA6E-491E-8CAF-6F3899717619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In Drivechain, 51% of miners have total control and ownership over all =
of the sidechain coins. The vision of Drivechain is to have many =
blockchains "plugged in" to the main chain.

Today, well over 51% of miners are under the jurisdiction of a single =
government.

Thus the effect of Drivechain appears to be the creation of a new kind =
of digital border imposed onto the network where everyone hands over =
ownership of their Bitcoins to a /single/ mining cartel when they wish =
to interact with /any/ sidechain.

Drivechain would be a reasonable idea if that weren't the case, but =
since it is, Drivechain now introduces a very real possible future where =
Bitcoins can be confiscated by the Chinese government in exactly the =
same manner that the Chinese government today confiscates financial =
assets in other financial networks within China.

One argument is that the psuedo-anonymity granted by Bitcoin addresses =
could theoretically make this less likely to happen, and while that is =
true, it is also true that every day Bitcoin becomes less and less =
psuedo-anonymous as governments invest in blockchain analysis tech [1].

How many high-profile confiscations =E2=80=94 now via the =
Bitcoin-blockchain itself (no longer being able to blame a 3rd-party =
exchange) =E2=80=94 is Bitcoin willing to tolerate and open itself up =
to?

In a world before Drivechain: the worst that a 51% coalition can do is =
prevent you from spending your coins (censorship).

In a world with Drivechain three things become true:

1. The Bitcoin network centralizes more, because more power (both =
financial power and power in terms of capability/control) is granted to =
miners. This is likely to have secondary consequences on the main-chain =
network as well (in terms of its price and ability to evolve).

2. A 51% coalition =E2=80=94 and/or the government behind it =E2=80=94 =
is now able to financially profit by confiscating coins. No longer is it =
just censorship, "asset forfeiture" =E2=80=94 theft =E2=80=94 becomes a =
real possibility for day-to-day Bitcoin users.

3. Drivechain limits user's existing choice when it comes to who is =
acting as custodian of their Bitcoins, from any trustworthy exchange, =
down to a single mining cartel under the control of a single set of =
laws.

The argument given to this is that a UASF could be initiated to wrest =
control away from this cartel. I do not believe this addresses the =
concern at all.

A UASF is a very big deal and extremely difficult to pull off correctly. =
Even when you have users behind you, it *requires* significant support =
from the miners themselves [2]. Therefore, I do not believe a UASF is a =
realistic possibility for recovery.

I would only support Drivechain if all of these issue were addressed.

Kind regards,
Greg Slepak

[1] EU Commits =E2=82=AC5 Million to Fund Blockchain Surveillance =
Research =E2=80=94 =
http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance=
-research/ =
<http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillanc=
e-research/>

[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.h=
tml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.=
html>

--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.

> On Jun 10, 2017, at 10:04 AM, Paul Sztorc via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
> Hi everyone,
>=20
> It has been 3 weeks -- responses so far have been really helpful. =
People
> jumped right in, and identified unfinished or missing parts much =
faster
> than I thought they would (ie, ~two days). Very impressive.
>=20
> Currently, we are working on the sidechain side of blind merged =
mining.
> As you know, most of the Bitcoin cryptosystem is about finding the
> longest chain, and displaying information about this chain. CryptAxe =
is
> editing the sidechain code to handle reorganizations in a new way (an
> even bigger departure than Namecoin's, imho).
>=20
> I believe that I have responded to all the on-list objections that =
were
> raised. I will 1st summarize the on-list objections, and 2nd summarize
> the off-list discussion (focusing on three key themes).
>=20
>=20
> On-List Objection Summary
> ---------------------------
>=20
> In general, they were:
>=20
> * Peter complained about the resources required for the BMM 'crisis
> audit', I pointed out that it is actually optional (and, therefore,
> free), and that it doesn't affect miners relative to each other, and
> that it can be done in an ultra-cheap semi-trusted way with high
> reliability.
> * Peter also asked about miner incentives, I replied that it is profit
> maximizing to BMM sidechains, because the equation (Tx Fees - Zero =
Cost)
> is always positive.
> * ZmnSCPxj asked a long series of clarifying questions, and I =
responded.
> * Tier Nolan complained about my equivocation of the "Bitcoin: no =
block
> subsidy" case and the "sidechain" case. He cites the asymmetry I point
> out below (in #2). I replied, and I give an answer below.
> * ZmnSCPxj pointed out an error in our OP Code (that we will fix).
> * ZmnSCPxj also asked a number of new questions, I responded. Then he
> responded again, in general he seemed to raise many of the points
> addressed in #1 (below).
> * ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
> that if 51% can reorg, they can also filter out the reorg proof. We =
are
> at their mercy in all cases (for better or worse).
> * ZmnSCPxj also brought up the fact that a block size limit is =
necessary
> for a fee market, I pointed out that this limit does not need to be
> imposed on miners by nodes...miners would be willing-and-able to
> self-impose such a limit, as it maximizes their revenues.
> * ZmnSCPxj also protested the need to soft fork in each individual
> sidechain, I pointed out my strong disagreement ("Unrestrained smart
> contract execution will be the death of most of the interesting
> applications...[could] destabilize Bitcoin itself") and introduced my
> prion metaphor.
> * ZmnSCPxj and Tier Nolan both identified the problem solved by our
> 'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
> coded it at the time, but there is code for it now [1]. Tier proposed =
a
> rachet design, but I think ours is better (Tier did not find ours at
> all, because it is buried in obscure notes, because I didn't think
> anyone would make it this far so quickly).
> * Tier also advised us on how to fix the problem that ZmnSCPxj had
> identified with our NOP earlier.
> * Tier also had a number of suggestions about the real-time =
negotiation
> of the OP Bribe amount between nodes and miners. I'm afraid I mostly
> ignored these for now, as we aren't there yet.
> * Peter complained that ACKing the sidechain could be exploited for
> political reasons, and I responded that in such a case, miners are =
free
> to simply avoid ACKing, or to acquiesce to political pressure. Neither
> affect the mainchain.
> * Peter complained that sidechains might provide some miners with the
> opportunity to create a pretext to kick other miners off the network. =
I
> replied that it would not, and I also brought up the fact that my
> Bitcoin security model was indifferent to which people happened to be
> mining at any given time. I continue to believe that "mining
> centralization" does not have a useful definition.
> * Peter questioned whether or not sidechains would be useful. I stated
> my belief that they would be useful, and linked to my site
> (drivechain.info/projects <http://drivechain.info/projects>) which =
contains a number of sidechain
> use-cases, and cited my personal anecdotal experiences.
> * Peter wanted to involve miners "as little as possible", I pointed =
out
> that I felt that I had indeed done this minimization. My view is that
> Peter felt erroneously that it was possible to involve miners less,
> because he neglected [1] that a 51% miner group is already involved
> maximally, as they can create most messages and filter any message, =
and
> [2] that there are cases where we need miners to filter out harmful
> interactions among multiple chains (just as they filter out harmful
> interactions among multiple txns [ie, "double spends"]). Peter has not
> yet responded to this rebuttal.
> * Peter also suggested client-side validation as "safer", and I =
pointed
> out that sidechains+BMM _is_ client-side validation. I asked Peter for
> CS-V code, so that we can compare the safety and other features.
> * Sergio reminded us of his version of drivechain. Sergio and I =
disagree
> over the emphasis on frequency/speed of withdrawals. Also Sergio
> emphasizes a hybrid model, which does not interest me.
>=20
> If I missed any objections, I hope someone will point them out.
>=20
>=20
> Off-List / Three Points of Ongoing Confusion
> ---------------------------------------------
>=20
> Off list, I have repeated the a similar conversation perhaps 6-10 =
times
> over the past week. There is a cluster of remaining objections which
> centers around three topics -- speed, theft, and antifragility. I will
> reply here, and add the answers to my FAQ (drivechain.info/faq =
<http://drivechain.info/faq>).
>=20
> 1. Speed
>=20
> This objection is voiced after I point out that side-to-main transfers
> ("withdrawals") will probably take a long time, for example 5 months
> each ( these are customizable parameters, and open for debate -- but =
if
> withdrawals are every x=3D3 months, and only x=3D1 withdrawal can make
> forward progress [on the mainchain] at a time, and only x=3D1 =
prospective
> withdrawal can be assembled [by the sidechain] at a time, then we can
> expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
> response is something like "won't such a system be too slow, and
> therefore unusable?".
>=20
> Imho, replies of this kind disregard the effect of atomic cross-chain
> swaps, which are instant.
>=20
> ( In addition, while side-to-main transfers are slow, main-to-side
> transfers are quite fast, x~=3D10 confirmations. I would go as far as =
to
> say that, just as the Lightning Network is enabled by SegWit and CSV,
> Drivechain is enabled by the atomic swaps and of Counterparty-like
> embedded consensus. )
>=20
> Thanks to atomic swaps, someone can act as an investment banker or
> custodian, and purchase side:BTC at a (tiny, competitive discount) and
> then transfer those side-to-main at a minimal inconvenience =
(comparable
> to that of someone who buys a bank CD). Through market activities, the
> _entire system_ becomes exactly as patient as its most-patient =
members.
> As icing on the cake, people who aren't planning on using their BTC
> anytime soon (ie "the patient") can even get a tiny investment yield, =
in
> return for providing this service.
>=20
>=20
> 2. Security
>=20
> This objection usually says something like "Aren't you worried that =
51%
> [hashrate] will steal the coins, given that mining is so centralized
> these days?"
>=20
> The logic of drivechain is to take a known fact -- that miners do not
> steal from exchanges (by coordinating to doublespend deposits to those
> exchanges) -- and generalize it to a new situation -- that [hopefully]
> miners will not steal from sidechains (by coordinating to make =
'invalid'
> withdrawals from them).
>=20
> My generalization is slightly problematic, because "a large mainchain
> reorg today" would hit the entire Bitcoin system and de-confirm *all* =
of
> the network's transactions, whereas a sidechain-theft would hit only a
> small portion of the system. This asymmetry is a problem because of =
the
> 1:1 peg, which is explicitly symmetrical -- the thief makes off coins
> that are worth _just as much_ as those coins that he did _not_ attack.
> The side:BTC are therefore relatively more vulnerable to theft, which
> harms the generalization.
>=20
> As I've just explained, to correct this relative deficiency, we add
> extra inconvenience for any sidechain thievery, which is in this case
> the long long withdrawal time of several months. (Which is also the =
main
> distinction between DC and extension blocks).
>=20
> I cannot realistically imagine an erroneous withdrawal persisting for
> several weeks, let alone several months. First, over a timeframe of =
this
> duration, there can be no pretense of 'we made an innocent mistake', =
nor
> one that 'it is too inconvenient for us to fix this problem'. This
> requires the attacker to be part of an explicitly malicious =
conspiracy.
> Even in the conspiring case, I do not understand how miners would
> coordinate the distribution of the eventual "theft" payout, ~3 months
> from now -- if new hashrate comes online between now and then, does it
> get a portion? -- if today's hashrate closes down, does it get a =
reduced
> portion? -- who decides? I don't think that an algorithm can decide
> (without creating a new mechanism, which -I believe- would have to be
> powered by ongoing sustainable theft [which is impossible]), because =
the
> withdrawal (ie the "theft") has to be initiated, with a known
> destination, *before* it accumulates 3 months worth of =
acknowledgement.
>=20
> Even if hashrate were controlled exclusively by one person, such a =
theft
> would obliterate the sidechain-tx-fee revenue from all sidechains, for =
a
> start. It would also greatly reduce the market price of [mainchain] =
BTC,
> I feel, as it ends the sidechain experiment more-or-less permanently.
>=20
> And even _that_ dire situation can be defeated by UASF-style =
maneuvers,
> such as checkpointing. Even the threat of such maneuvers can be
> persuasive enough for them never to be needed (especially over long
> timeframes, which make these maneuvers convenient).
>=20
> A slightly more realistic worst-case scenario is that a monopolist
> imposes large fees on side-to-main transfers (which he contrives so =
that
> only he can provide). Unless the monopoly is permanent, market forces
> (atomic swaps) will still lower the fee to ultra-competitive levels,
> making this mostly pointless.
>=20
>=20
> 3. Antifragility
>=20
> There is an absolutely crucial distinction of "layers", which is often
> overlooked. Which is a shame, because its importance really cannot be
> understated.
>=20
> Taleb's concept of antifragility is explicitly fractal -- it has =
layers,
> and an upper layer can only be antifragile if it is composed of
> individual members of a lower layer who are each *fragile*. In one of =
my
> videos I give the example of NYC food providers -- it is _because_ the
> competition is so brutal, and because each individual NYC
> restaurant/supermarket/food-truck is so likely to fail, (and because
> there is no safety net to catch them if they do fail), that the
> consumer's experience is so positive (in NYC, you can find almost any
> kind of food, at any hour of the day, at any price, despite the fact
> that a staggering ~15 million people will be eating there each day).
>=20
> By this, I mean there is an absolutely crucial distinction between:
>=20
> 1. A problem with a sidechain that negatively impacts its parent =
chain.
> 2. A problem with a sidechain that only impacts the sidechain users.
>=20
> The first type of problem is unacceptable, but the second type of
> problem is actually _desirable_.
>=20
> If we wanted to have the best BTC currency unit possible, we would =
want
> everyone to try all kinds of things out, _especially_ the things that =
we
> think are terrible. We'd want lots of things to be tried, and for the
> losers to "fail fast".
>=20
> In practice I highly doubt the sidechain ecosystem would be anywhere
> near as dynamic as NYC or Silicon Valley. But certain questions, such =
as
> "What if a sidechain breaks / has DAO-like problems?"; "What if the
> sidechain has only a few nodes? Who will run them?"; "Who will =
maintain
> these projects?"; -- really just miss the point, I think.
>=20
> Ultimately, users can vote with their feet -- if the benefits of a
> sidechain outweigh its risks, some users will send some BTC there. It =
is
> a strict improvement over the current situation, where users would =
need
> to use an Altcoin to achieve as much. Users who aren't comfortable =
with
> the risks of new chains / new features, can simply decline to use =
them.
>=20
>=20
> Another Objection
> ------------------
>=20
> Finally, two people raised an objection which I will call the "too
> popular" objection or "too big to fail (tbtf)". Something like "what =
if
> a *majority* of BTC is moved to one sidechain, and then that sidechain
> has some kind of problem?".
>=20
> One simple step would be to cap the quantity of BTC that can be moved =
to
> each sidechain, (at x=3D10% ? aka 210,000).
>=20
> Other than that, I would point out that Bitcoin has always been the
> "money of principle", and that we survived the MtGox announcement (in
> which ~850,000/12,400,000 =3D 6.85% of the total BTC were assumed to =
be
> stolen).
>=20
> I look forward to the continued feedback! Thank you all very much!
>=20
> Paul
>=20
> [1]
> =
https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e1=
1de7c044528bbde6c60 =
<https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e=
11de7c044528bbde6c60>
>=20
>=20
> On 5/22/2017 2:17 AM, Paul Sztorc wrote:
>> Dear list,
>>=20
>> I've been working on "drivechain", a sidechain enabling technology, =
for
>> some time.
>>=20
>> * The technical info site is here: www.drivechain.info
>> * The changes to Bitcoin are here:
>> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>> * A Blank sidechain template is here:
>> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>>=20
>> As many of you know, I've been seeking feedback in person, at various
>> conferences and meetups over the past year, most prominently Scaling
>> Milan. And I intend to continue to seek feedback at Consensus2017 =
this
>> week, so if you are in NYC please just walk up and start talking to =
me!
>>=20
>> But I also wanted to ask the list for feedback. Initially, I was
>> hesitant because I try not to consume reviewers' scarce time until =
the
>> author has put in a serious effort. However, I may have waiting too
>> long, as today it is actually quite close to a working release.
>>=20
>>=20
>> Scaling Implications
>> ---------------------
>>=20
>> This upgrade would have significant scaling implications. Since it is
>> the case that sidechains can be added by soft fork, and since each of
>> these chains will have its own blockspace, this theoretically removes
>> the blocksize limit from "the Bitcoin system" (if one includes
>> sidechains as part of such a system). People who want a LargeBlock
>> bitcoin can just move their BTC over to such a network [1], and their
>> txns will have no longer have an impact on "Bitcoin Core". Thus, even
>> though this upgrade does not actually increase "scalability" per se, =
it
>> may in fact put an end to the scalability debate...forever.
>>=20
>> This work includes the relatively new concept of "Blind Merged =
Mining"
>> [2] which I developed in January to allow SHA256^2 miners to =
merge-mine
>> these "drivechains", even if these miners aren't running the actual
>> sidechain software. The goal is to prevent sidechains from affecting =
the
>> levelness of the mining "playing field". BMM is conceptually similar =
to
>> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
>> required for drivechain, but it would address some of the last =
remaining
>> concerns.
>>=20
>>=20
>> Total Transaction Fees in the Far Future
>> -----------------------------------------
>>=20
>> Some people feel that a maximum blocksize limit is needed to ensure =
that
>> future total equilibrium transaction fees are non-negligible. I
>> presented [4] on why I don't agree, 8 months ago. The reviewers I =
spoke
>> to over the last year have stopped bringing this complaint up, but I =
am
>> not sure everyone feels that way.
>>=20
>>=20
>> Juxtaposition with a recent "Scaling Compromise"
>> -------------------------------------------------
>>=20
>> Recently, a scalability proposal began to circulate on social media. =
As
>> far as I could tell, it goes something like "immediately activate
>> SegWit, and then HF to double the nonwitness blockspace to 2MB within =
12
>> months". But such a proposal is quite meager, compared to a =
"LargeBlock
>> Drivechain". The drivechain is better on both fronts, as it would not
>> require a hardfork, and could *almost immediately* add _any_ amount =
of
>> extra blockspace (specifically, I might expect a BIP101-like =
LargeBlock
>> chain that has an 8 MB maxblocksize, which doubles every two years).
>>=20
>> In other words, I don't know why anyone would support that proposal =
over
>> mine. The only reasons would be either ignorance (ie, unfamiliarity =
with
>> drivechain) or because there are still nagging unspoken complaints =
about
>> drivechain which I apparently need to hear and address.
>>=20
>>=20
>> Other Thoughts
>> ---------------
>>=20
>> Unfortunately, anyone who worked on the "first generation" of =
sidechain
>> technology (the skiplist) or the "second generation" (federated /
>> Liquid), will find that this is very different.
>>=20
>> I will admit that I am very pessimistic about any conversation that
>> involves scalability. It is often said that "talking politics lowers
>> your IQ by 25 points". Bitcoin scalability conversations seem to =
drain
>> 50 points. (Instead of conversing, I think people should quietly work =
on
>> whatever they are passionate about until their problem either is =
solved,
>> or it goes away for some other reason, or until we all agree to just
>> stop talking about it.)
>>=20
>> Cheers,
>> Paul
>>=20
>> [1] =
http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
>> [2] http://www.truthcoin.info/blog/blind-merged-mining/
>> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
>> [4]
>> =
https://www.youtube.com/watch?v=3DYErLEuOi3xU&list=3DPLw8-6ARlyVciNjgS_NFh=
Au-qt7HPf_dtg&index=3D4
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_B717153B-DA6E-491E-8CAF-6F3899717619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">In Drivechain, 51% of miners have total =
control and ownership over all of the sidechain coins. The vision of =
Drivechain is to have many blockchains "plugged in" to the main =
chain.</div><div class=3D""><br class=3D""></div><div class=3D"">Today, =
well over 51% of miners are under the jurisdiction of a single =
government.</div><div class=3D""><br class=3D""></div><div class=3D"">Thus=
 the effect of Drivechain appears to be the creation of a new kind of =
digital border imposed onto the network where everyone hands over =
ownership of their Bitcoins to a /single/ mining cartel when they wish =
to interact with /any/ sidechain.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Drivechain would be a reasonable idea =
if that weren't the case, but since it is, Drivechain now introduces a =
very real possible future where Bitcoins can be confiscated by the =
Chinese government in exactly the same manner that the Chinese =
government today confiscates financial assets in other financial =
networks within China.</div><div class=3D""><br class=3D""></div><div =
class=3D"">One argument is that the psuedo-anonymity granted by Bitcoin =
addresses could theoretically make this less likely to happen, and while =
that is true, it is also true that every day Bitcoin becomes less and =
less psuedo-anonymous as governments invest in blockchain analysis tech =
[1].</div><div class=3D""><br class=3D""></div><div class=3D"">How many =
high-profile confiscations =E2=80=94 now via the Bitcoin-blockchain =
itself (no longer being able to blame a 3rd-party exchange) =E2=80=94 is =
Bitcoin willing to tolerate and open itself up to?</div><div =
class=3D""><br class=3D""></div><div class=3D"">In a world before =
Drivechain: the worst that a 51% coalition can do is prevent you from =
spending your coins (censorship).</div><div class=3D""><br =
class=3D""></div><div class=3D"">In a world with Drivechain three things =
become true:</div><div class=3D""><br class=3D""></div><div class=3D"">1. =
The Bitcoin network centralizes more, because more power (both financial =
power and power in terms of capability/control) is granted to miners. =
This is likely to have secondary consequences on the main-chain network =
as well (in terms of its price and ability to evolve).</div><div =
class=3D""><br class=3D""></div><div class=3D"">2. A 51% coalition =E2=80=94=
 and/or the government behind it =E2=80=94 is now able to financially =
profit by confiscating coins. No longer is it just censorship, "asset =
forfeiture" =E2=80=94 theft =E2=80=94 becomes a real possibility for =
day-to-day Bitcoin users.</div><div class=3D""><br class=3D""></div><div =
class=3D"">3. Drivechain limits user's existing choice when it comes to =
who is acting as custodian of their Bitcoins, from any trustworthy =
exchange, down to a single mining cartel under the control of a single =
set of laws.</div><div class=3D""><br class=3D""></div><div class=3D"">The=
 argument given to this is that a UASF could be initiated to wrest =
control away from this cartel. I do not believe this addresses the =
concern at all.</div><div class=3D""><br class=3D""></div><div =
class=3D"">A UASF is a very big deal and extremely difficult to pull off =
correctly. Even when you have users behind you, it *requires* =
significant support from the miners themselves [2]. Therefore, I do not =
believe a UASF is a realistic possibility for recovery.</div><div =
class=3D""><br class=3D""></div><div class=3D"">I would only support =
Drivechain if all of these issue were addressed.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Kind regards,</div><div class=3D"">Greg =
Slepak</div><div class=3D""><br class=3D""></div><div =
class=3D"">[1]&nbsp;EU Commits =E2=82=AC5 Million to Fund Blockchain =
Surveillance Research =E2=80=94 <a =
href=3D"http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surv=
eillance-research/" =
class=3D"">http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-s=
urveillance-research/</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">[2]&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/=
014497.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju=
ne/014497.html</a></div><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D""><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">--</span><br style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D""><span style=3D"color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 14px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">Please do not email me anything that you are not =
comfortable also sharing</span><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">&nbsp;with the NSA.</span>
</div>

<br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 10, 2017, at 10:04 AM, Paul Sztorc via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Hi =
everyone,<br class=3D""><br class=3D"">It has been 3 weeks -- responses =
so far have been really helpful. People<br class=3D"">jumped right in, =
and identified unfinished or missing parts much faster<br class=3D"">than =
I thought they would (ie, ~two days). Very impressive.<br class=3D""><br =
class=3D"">Currently, we are working on the sidechain side of blind =
merged mining.<br class=3D"">As you know, most of the Bitcoin =
cryptosystem is about finding the<br class=3D"">longest chain, and =
displaying information about this chain. CryptAxe is<br class=3D"">editing=
 the sidechain code to handle reorganizations in a new way (an<br =
class=3D"">even bigger departure than Namecoin's, imho).<br class=3D""><br=
 class=3D"">I believe that I have responded to all the on-list =
objections that were<br class=3D"">raised. I will 1st summarize the =
on-list objections, and 2nd summarize<br class=3D"">the off-list =
discussion (focusing on three key themes).<br class=3D""><br =
class=3D""><br class=3D"">On-List Objection Summary<br =
class=3D"">---------------------------<br class=3D""><br class=3D"">In =
general, they were:<br class=3D""><br class=3D"">* Peter complained =
about the resources required for the BMM 'crisis<br class=3D"">audit', I =
pointed out that it is actually optional (and, therefore,<br =
class=3D"">free), and that it doesn't affect miners relative to each =
other, and<br class=3D"">that it can be done in an ultra-cheap =
semi-trusted way with high<br class=3D"">reliability.<br class=3D"">* =
Peter also asked about miner incentives, I replied that it is profit<br =
class=3D"">maximizing to BMM sidechains, because the equation (Tx Fees - =
Zero Cost)<br class=3D"">is always positive.<br class=3D"">* ZmnSCPxj =
asked a long series of clarifying questions, and I responded.<br =
class=3D"">* Tier Nolan complained about my equivocation of the =
"Bitcoin: no block<br class=3D"">subsidy" case and the "sidechain" case. =
He cites the asymmetry I point<br class=3D"">out below (in #2). I =
replied, and I give an answer below.<br class=3D"">* ZmnSCPxj pointed =
out an error in our OP Code (that we will fix).<br class=3D"">* ZmnSCPxj =
also asked a number of new questions, I responded. Then he<br =
class=3D"">responded again, in general he seemed to raise many of the =
points<br class=3D"">addressed in #1 (below).<br class=3D"">* ZmnSCPxj =
wanted reorg proofs, to punish reorgers, but I pointed out<br =
class=3D"">that if 51% can reorg, they can also filter out the reorg =
proof. We are<br class=3D"">at their mercy in all cases (for better or =
worse).<br class=3D"">* ZmnSCPxj also brought up the fact that a block =
size limit is necessary<br class=3D"">for a fee market, I pointed out =
that this limit does not need to be<br class=3D"">imposed on miners by =
nodes...miners would be willing-and-able to<br class=3D"">self-impose =
such a limit, as it maximizes their revenues.<br class=3D"">* ZmnSCPxj =
also protested the need to soft fork in each individual<br =
class=3D"">sidechain, I pointed out my strong disagreement =
("Unrestrained smart<br class=3D"">contract execution will be the death =
of most of the interesting<br class=3D"">applications...[could] =
destabilize Bitcoin itself") and introduced my<br class=3D"">prion =
metaphor.<br class=3D"">* ZmnSCPxj and Tier Nolan both identified the =
problem solved by our<br class=3D"">'ratchet' concept. I explained it to =
ZmnSCPxj in my reply. We had not<br class=3D"">coded it at the time, but =
there is code for it now [1]. Tier proposed a<br class=3D"">rachet =
design, but I think ours is better (Tier did not find ours at<br =
class=3D"">all, because it is buried in obscure notes, because I didn't =
think<br class=3D"">anyone would make it this far so quickly).<br =
class=3D"">* Tier also advised us on how to fix the problem that =
ZmnSCPxj had<br class=3D"">identified with our NOP earlier.<br =
class=3D"">* Tier also had a number of suggestions about the real-time =
negotiation<br class=3D"">of the OP Bribe amount between nodes and =
miners. I'm afraid I mostly<br class=3D"">ignored these for now, as we =
aren't there yet.<br class=3D"">* Peter complained that ACKing the =
sidechain could be exploited for<br class=3D"">political reasons, and I =
responded that in such a case, miners are free<br class=3D"">to simply =
avoid ACKing, or to acquiesce to political pressure. Neither<br =
class=3D"">affect the mainchain.<br class=3D"">* Peter complained that =
sidechains might provide some miners with the<br class=3D"">opportunity =
to create a pretext to kick other miners off the network. I<br =
class=3D"">replied that it would not, and I also brought up the fact =
that my<br class=3D"">Bitcoin security model was indifferent to which =
people happened to be<br class=3D"">mining at any given time. I continue =
to believe that "mining<br class=3D"">centralization" does not have a =
useful definition.<br class=3D"">* Peter questioned whether or not =
sidechains would be useful. I stated<br class=3D"">my belief that they =
would be useful, and linked to my site<br class=3D"">(<a =
href=3D"http://drivechain.info/projects" =
class=3D"">drivechain.info/projects</a>) which contains a number of =
sidechain<br class=3D"">use-cases, and cited my personal anecdotal =
experiences.<br class=3D"">* Peter wanted to involve miners "as little =
as possible", I pointed out<br class=3D"">that I felt that I had indeed =
done this minimization. My view is that<br class=3D"">Peter felt =
erroneously that it was possible to involve miners less,<br =
class=3D"">because he neglected [1] that a 51% miner group is already =
involved<br class=3D"">maximally, as they can create most messages and =
filter any message, and<br class=3D"">[2] that there are cases where we =
need miners to filter out harmful<br class=3D"">interactions among =
multiple chains (just as they filter out harmful<br =
class=3D"">interactions among multiple txns [ie, "double spends"]). =
Peter has not<br class=3D"">yet responded to this rebuttal.<br =
class=3D"">* Peter also suggested client-side validation as "safer", and =
I pointed<br class=3D"">out that sidechains+BMM _is_ client-side =
validation. I asked Peter for<br class=3D"">CS-V code, so that we can =
compare the safety and other features.<br class=3D"">* Sergio reminded =
us of his version of drivechain. Sergio and I disagree<br class=3D"">over =
the emphasis on frequency/speed of withdrawals. Also Sergio<br =
class=3D"">emphasizes a hybrid model, which does not interest me.<br =
class=3D""><br class=3D"">If I missed any objections, I hope someone =
will point them out.<br class=3D""><br class=3D""><br class=3D"">Off-List =
/ Three Points of Ongoing Confusion<br =
class=3D"">---------------------------------------------<br class=3D""><br=
 class=3D"">Off list, I have repeated the a similar conversation perhaps =
6-10 times<br class=3D"">over the past week. There is a cluster of =
remaining objections which<br class=3D"">centers around three topics -- =
speed, theft, and antifragility. I will<br class=3D"">reply here, and =
add the answers to my FAQ (<a href=3D"http://drivechain.info/faq" =
class=3D"">drivechain.info/faq</a>).<br class=3D""><br class=3D"">1. =
Speed<br class=3D""><br class=3D"">This objection is voiced after I =
point out that side-to-main transfers<br class=3D"">("withdrawals") will =
probably take a long time, for example 5 months<br class=3D"">each ( =
these are customizable parameters, and open for debate -- but if<br =
class=3D"">withdrawals are every x=3D3 months, and only x=3D1 withdrawal =
can make<br class=3D"">forward progress [on the mainchain] at a time, =
and only x=3D1 prospective<br class=3D"">withdrawal can be assembled [by =
the sidechain] at a time, then we can<br class=3D"">expect total =
withdrawal time to average 4.5 months [(.5)*3+3] ). The<br =
class=3D"">response is something like "won't such a system be too slow, =
and<br class=3D"">therefore unusable?".<br class=3D""><br class=3D"">Imho,=
 replies of this kind disregard the effect of atomic cross-chain<br =
class=3D"">swaps, which are instant.<br class=3D""><br class=3D"">( In =
addition, while side-to-main transfers are slow, main-to-side<br =
class=3D"">transfers are quite fast, x~=3D10 confirmations. I would go =
as far as to<br class=3D"">say that, just as the Lightning Network is =
enabled by SegWit and CSV,<br class=3D"">Drivechain is enabled by the =
atomic swaps and of Counterparty-like<br class=3D"">embedded consensus. =
)<br class=3D""><br class=3D"">Thanks to atomic swaps, someone can act =
as an investment banker or<br class=3D"">custodian, and purchase =
side:BTC at a (tiny, competitive discount) and<br class=3D"">then =
transfer those side-to-main at a minimal inconvenience (comparable<br =
class=3D"">to that of someone who buys a bank CD). Through market =
activities, the<br class=3D"">_entire system_ becomes exactly as patient =
as its most-patient members.<br class=3D"">As icing on the cake, people =
who aren't planning on using their BTC<br class=3D"">anytime soon (ie =
"the patient") can even get a tiny investment yield, in<br =
class=3D"">return for providing this service.<br class=3D""><br =
class=3D""><br class=3D"">2. Security<br class=3D""><br class=3D"">This =
objection usually says something like "Aren't you worried that 51%<br =
class=3D"">[hashrate] will steal the coins, given that mining is so =
centralized<br class=3D"">these days?"<br class=3D""><br class=3D"">The =
logic of drivechain is to take a known fact -- that miners do not<br =
class=3D"">steal from exchanges (by coordinating to doublespend deposits =
to those<br class=3D"">exchanges) -- and generalize it to a new =
situation -- that [hopefully]<br class=3D"">miners will not steal from =
sidechains (by coordinating to make 'invalid'<br class=3D"">withdrawals =
from them).<br class=3D""><br class=3D"">My generalization is slightly =
problematic, because "a large mainchain<br class=3D"">reorg today" would =
hit the entire Bitcoin system and de-confirm *all* of<br class=3D"">the =
network's transactions, whereas a sidechain-theft would hit only a<br =
class=3D"">small portion of the system. This asymmetry is a problem =
because of the<br class=3D"">1:1 peg, which is explicitly symmetrical -- =
the thief makes off coins<br class=3D"">that are worth _just as much_ as =
those coins that he did _not_ attack.<br class=3D"">The side:BTC are =
therefore relatively more vulnerable to theft, which<br class=3D"">harms =
the generalization.<br class=3D""><br class=3D"">As I've just explained, =
to correct this relative deficiency, we add<br class=3D"">extra =
inconvenience for any sidechain thievery, which is in this case<br =
class=3D"">the long long withdrawal time of several months. (Which is =
also the main<br class=3D"">distinction between DC and extension =
blocks).<br class=3D""><br class=3D"">I cannot realistically imagine an =
erroneous withdrawal persisting for<br class=3D"">several weeks, let =
alone several months. First, over a timeframe of this<br =
class=3D"">duration, there can be no pretense of 'we made an innocent =
mistake', nor<br class=3D"">one that 'it is too inconvenient for us to =
fix this problem'. This<br class=3D"">requires the attacker to be part =
of an explicitly malicious conspiracy.<br class=3D"">Even in the =
conspiring case, I do not understand how miners would<br =
class=3D"">coordinate the distribution of the eventual "theft" payout, =
~3 months<br class=3D"">from now -- if new hashrate comes online between =
now and then, does it<br class=3D"">get a portion? -- if today's =
hashrate closes down, does it get a reduced<br class=3D"">portion? -- =
who decides? I don't think that an algorithm can decide<br =
class=3D"">(without creating a new mechanism, which -I believe- would =
have to be<br class=3D"">powered by ongoing sustainable theft [which is =
impossible]), because the<br class=3D"">withdrawal (ie the "theft") has =
to be initiated, with a known<br class=3D"">destination, *before* it =
accumulates 3 months worth of acknowledgement.<br class=3D""><br =
class=3D"">Even if hashrate were controlled exclusively by one person, =
such a theft<br class=3D"">would obliterate the sidechain-tx-fee revenue =
from all sidechains, for a<br class=3D"">start. It would also greatly =
reduce the market price of [mainchain] BTC,<br class=3D"">I feel, as it =
ends the sidechain experiment more-or-less permanently.<br class=3D""><br =
class=3D"">And even _that_ dire situation can be defeated by UASF-style =
maneuvers,<br class=3D"">such as checkpointing. Even the threat of such =
maneuvers can be<br class=3D"">persuasive enough for them never to be =
needed (especially over long<br class=3D"">timeframes, which make these =
maneuvers convenient).<br class=3D""><br class=3D"">A slightly more =
realistic worst-case scenario is that a monopolist<br class=3D"">imposes =
large fees on side-to-main transfers (which he contrives so that<br =
class=3D"">only he can provide). Unless the monopoly is permanent, =
market forces<br class=3D"">(atomic swaps) will still lower the fee to =
ultra-competitive levels,<br class=3D"">making this mostly pointless.<br =
class=3D""><br class=3D""><br class=3D"">3. Antifragility<br =
class=3D""><br class=3D"">There is an absolutely crucial distinction of =
"layers", which is often<br class=3D"">overlooked. Which is a shame, =
because its importance really cannot be<br class=3D"">understated.<br =
class=3D""><br class=3D"">Taleb's concept of antifragility is explicitly =
fractal -- it has layers,<br class=3D"">and an upper layer can only be =
antifragile if it is composed of<br class=3D"">individual members of a =
lower layer who are each *fragile*. In one of my<br class=3D"">videos I =
give the example of NYC food providers -- it is _because_ the<br =
class=3D"">competition is so brutal, and because each individual NYC<br =
class=3D"">restaurant/supermarket/food-truck is so likely to fail, (and =
because<br class=3D"">there is no safety net to catch them if they do =
fail), that the<br class=3D"">consumer's experience is so positive (in =
NYC, you can find almost any<br class=3D"">kind of food, at any hour of =
the day, at any price, despite the fact<br class=3D"">that a staggering =
~15 million people will be eating there each day).<br class=3D""><br =
class=3D"">By this, I mean there is an absolutely crucial distinction =
between:<br class=3D""><br class=3D"">1. A problem with a sidechain that =
negatively impacts its parent chain.<br class=3D"">2. A problem with a =
sidechain that only impacts the sidechain users.<br class=3D""><br =
class=3D"">The first type of problem is unacceptable, but the second =
type of<br class=3D"">problem is actually _desirable_.<br class=3D""><br =
class=3D"">If we wanted to have the best BTC currency unit possible, we =
would want<br class=3D"">everyone to try all kinds of things out, =
_especially_ the things that we<br class=3D"">think are terrible. We'd =
want lots of things to be tried, and for the<br class=3D"">losers to =
"fail fast".<br class=3D""><br class=3D"">In practice I highly doubt the =
sidechain ecosystem would be anywhere<br class=3D"">near as dynamic as =
NYC or Silicon Valley. But certain questions, such as<br class=3D"">"What =
if a sidechain breaks / has DAO-like problems?"; "What if the<br =
class=3D"">sidechain has only a few nodes? Who will run them?"; "Who =
will maintain<br class=3D"">these projects?"; -- really just miss the =
point, I think.<br class=3D""><br class=3D"">Ultimately, users can vote =
with their feet -- if the benefits of a<br class=3D"">sidechain outweigh =
its risks, some users will send some BTC there. It is<br class=3D"">a =
strict improvement over the current situation, where users would need<br =
class=3D"">to use an Altcoin to achieve as much. Users who aren't =
comfortable with<br class=3D"">the risks of new chains / new features, =
can simply decline to use them.<br class=3D""><br class=3D""><br =
class=3D"">Another Objection<br class=3D"">------------------<br =
class=3D""><br class=3D"">Finally, two people raised an objection which =
I will call the "too<br class=3D"">popular" objection or "too big to =
fail (tbtf)". Something like "what if<br class=3D"">a *majority* of BTC =
is moved to one sidechain, and then that sidechain<br class=3D"">has =
some kind of problem?".<br class=3D""><br class=3D"">One simple step =
would be to cap the quantity of BTC that can be moved to<br =
class=3D"">each sidechain, (at x=3D10% ? aka 210,000).<br class=3D""><br =
class=3D"">Other than that, I would point out that Bitcoin has always =
been the<br class=3D"">"money of principle", and that we survived the =
MtGox announcement (in<br class=3D"">which ~850,000/12,400,000 =3D 6.85% =
of the total BTC were assumed to be<br class=3D"">stolen).<br =
class=3D""><br class=3D"">I look forward to the continued feedback! =
Thank you all very much!<br class=3D""><br class=3D"">Paul<br =
class=3D""><br class=3D"">[1]<br class=3D""><a =
href=3D"https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e=
52d2c1e11de7c044528bbde6c60" =
class=3D"">https://github.com/drivechain-project/bitcoin/commit/c4beef5c2a=
a8e52d2c1e11de7c044528bbde6c60</a><br class=3D""><br class=3D""><br =
class=3D"">On 5/22/2017 2:17 AM, Paul Sztorc wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">Dear list,<br =
class=3D""><br class=3D"">I've been working on "drivechain", a sidechain =
enabling technology, for<br class=3D"">some time.<br class=3D""><br =
class=3D"">* The technical info site is here: <a =
href=3D"http://www.drivechain.info" class=3D"">www.drivechain.info</a><br =
class=3D"">* The changes to Bitcoin are here:<br class=3D""><a =
href=3D"https://github.com/drivechain-project/bitcoin/tree/mainchainBMM" =
class=3D"">https://github.com/drivechain-project/bitcoin/tree/mainchainBMM=
</a><br class=3D"">* A Blank sidechain template is here:<br =
class=3D"">https://github.com/drivechain-project/bitcoin/tree/sidechainBMM=
<br class=3D""><br class=3D"">As many of you know, I've been seeking =
feedback in person, at various<br class=3D"">conferences and meetups =
over the past year, most prominently Scaling<br class=3D"">Milan. And I =
intend to continue to seek feedback at Consensus2017 this<br =
class=3D"">week, so if you are in NYC please just walk up and start =
talking to me!<br class=3D""><br class=3D"">But I also wanted to ask the =
list for feedback. Initially, I was<br class=3D"">hesitant because I try =
not to consume reviewers' scarce time until the<br class=3D"">author has =
put in a serious effort. However, I may have waiting too<br =
class=3D"">long, as today it is actually quite close to a working =
release.<br class=3D""><br class=3D""><br class=3D"">Scaling =
Implications<br class=3D"">---------------------<br class=3D""><br =
class=3D"">This upgrade would have significant scaling implications. =
Since it is<br class=3D"">the case that sidechains can be added by soft =
fork, and since each of<br class=3D"">these chains will have its own =
blockspace, this theoretically removes<br class=3D"">the blocksize limit =
from "the Bitcoin system" (if one includes<br class=3D"">sidechains as =
part of such a system). People who want a LargeBlock<br class=3D"">bitcoin=
 can just move their BTC over to such a network [1], and their<br =
class=3D"">txns will have no longer have an impact on "Bitcoin Core". =
Thus, even<br class=3D"">though this upgrade does not actually increase =
"scalability" per se, it<br class=3D"">may in fact put an end to the =
scalability debate...forever.<br class=3D""><br class=3D"">This work =
includes the relatively new concept of "Blind Merged Mining"<br =
class=3D"">[2] which I developed in January to allow SHA256^2 miners to =
merge-mine<br class=3D"">these "drivechains", even if these miners =
aren't running the actual<br class=3D"">sidechain software. The goal is =
to prevent sidechains from affecting the<br class=3D"">levelness of the =
mining "playing field". BMM is conceptually similar to<br =
class=3D"">ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is =
not<br class=3D"">required for drivechain, but it would address some of =
the last remaining<br class=3D"">concerns.<br class=3D""><br =
class=3D""><br class=3D"">Total Transaction Fees in the Far Future<br =
class=3D"">-----------------------------------------<br class=3D""><br =
class=3D"">Some people feel that a maximum blocksize limit is needed to =
ensure that<br class=3D"">future total equilibrium transaction fees are =
non-negligible. I<br class=3D"">presented [4] on why I don't agree, 8 =
months ago. The reviewers I spoke<br class=3D"">to over the last year =
have stopped bringing this complaint up, but I am<br class=3D"">not sure =
everyone feels that way.<br class=3D""><br class=3D""><br =
class=3D"">Juxtaposition with a recent "Scaling Compromise"<br =
class=3D"">-------------------------------------------------<br =
class=3D""><br class=3D"">Recently, a scalability proposal began to =
circulate on social media. As<br class=3D"">far as I could tell, it goes =
something like "immediately activate<br class=3D"">SegWit, and then HF =
to double the nonwitness blockspace to 2MB within 12<br =
class=3D"">months". But such a proposal is quite meager, compared to a =
"LargeBlock<br class=3D"">Drivechain". The drivechain is better on both =
fronts, as it would not<br class=3D"">require a hardfork, and could =
*almost immediately* add _any_ amount of<br class=3D"">extra blockspace =
(specifically, I might expect a BIP101-like LargeBlock<br class=3D"">chain=
 that has an 8 MB maxblocksize, which doubles every two years).<br =
class=3D""><br class=3D"">In other words, I don't know why anyone would =
support that proposal over<br class=3D"">mine. The only reasons would be =
either ignorance (ie, unfamiliarity with<br class=3D"">drivechain) or =
because there are still nagging unspoken complaints about<br =
class=3D"">drivechain which I apparently need to hear and address.<br =
class=3D""><br class=3D""><br class=3D"">Other Thoughts<br =
class=3D"">---------------<br class=3D""><br class=3D"">Unfortunately, =
anyone who worked on the "first generation" of sidechain<br =
class=3D"">technology (the skiplist) or the "second generation" =
(federated /<br class=3D"">Liquid), will find that this is very =
different.<br class=3D""><br class=3D"">I will admit that I am very =
pessimistic about any conversation that<br class=3D"">involves =
scalability. It is often said that "talking politics lowers<br =
class=3D"">your IQ by 25 points". Bitcoin scalability conversations seem =
to drain<br class=3D"">50 points. (Instead of conversing, I think people =
should quietly work on<br class=3D"">whatever they are passionate about =
until their problem either is solved,<br class=3D"">or it goes away for =
some other reason, or until we all agree to just<br class=3D"">stop =
talking about it.)<br class=3D""><br class=3D"">Cheers,<br =
class=3D"">Paul<br class=3D""><br class=3D"">[1] =
http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling<br=
 class=3D"">[2] http://www.truthcoin.info/blog/blind-merged-mining/<br =
class=3D"">[3] =
https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log<br =
class=3D"">[4]<br =
class=3D"">https://www.youtube.com/watch?v=3DYErLEuOi3xU&amp;list=3DPLw8-6=
ARlyVciNjgS_NFhAu-qt7HPf_dtg&amp;index=3D4<br class=3D""><br =
class=3D""></blockquote>_______________________________________________<br=
 class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_B717153B-DA6E-491E-8CAF-6F3899717619--

--Apple-Mail=_70A07552-0125-4749-8C1D-25D8A3F086CE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZRvELAAoJEOxnICvpCVJHEEgQAMrVAcyYEpV1yP2l7t3cLTJO
tgzqhj6+K25MnZ4P8gjMdN/XhV/5n1P07XKwcGKM2iSiKvpdOPG8YfGGRi9HcJT+
vMlYcZ/CjDTAiWdyWCIbymMn8pPHCpl7blSxA36xtvx+k36V3MtXgQDqvf5I2XnJ
nVvf4HQgAx//GAO3Pfv5pXWeYUwKsGyBauRLWWEN8uU6Q3UiPJA3ajlj3yvLdWap
z2JR+2Xyw/tIgxtjxpfgYSib8638X8fSEjHRcxFcd3rVvsxzHjiw/98YddHjtXHz
WQjNraHiChmSzpEe6Flm8KBZles5ksX5oc9Hd69pvg02csI1ip3GBmcI3ssTfKHi
HJ8dXieg2Qe6BZHB38sNmJwKxHrFBbCQhU9AwVY/h32YJb3PV2s5SY+XH93kNi+1
Cva4GgrKzUQVIXRe+qeZqG3+c0h9gmp3C4ktqvzqlJCRhVkmzsd8Xflf5qqO547M
0rDN4+YUuI5cXDujc7mnvvQy8cElb1iQ2LFpiz8A4pHo1WNmnkXT/JU2J1gUu3TU
m19qK/e92PQJ6hXuHn5gkzqDzsczL7CS1F2+7N8CAssa1LRtmsEtNma5yIadKGZb
th3WyNCrBhAiMo8PaHU77sY9QOWRAzk2qiPDl/xDmAN6cZMuvzNU3VDFoq1LHRQ3
Ze13N9mlYaUuSyeRT+zi
=r6+2
-----END PGP SIGNATURE-----

--Apple-Mail=_70A07552-0125-4749-8C1D-25D8A3F086CE--