path: root/4e/99723ce306377013ec437f54d043bfe3a7ce56

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 412A192B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 17:04:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
	[209.85.216.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99158198
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 17:04:15 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id w1so97792423qtg.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Jun 2017 10:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:from:to:references:message-id:date:user-agent:mime-version
	:in-reply-to:content-language:content-transfer-encoding;
	bh=SOyhymQ+MXZ1OVxbmcenwDvey6qX31Hw6SKF8Sl2fIk=;
	b=Y1AmM5LgeIt4sRGpAXrGo7pTMctKE2vewnks0e8U1k6lmMCJ94mnTLiLX1qPObWSUi
	stsz5MSlxOVTC5DHaS7htl/Fdrrw9YtnoSc8HcNCzR9IYkfoUz1a8LXOs/JmpHxpUaqF
	f/S+wqdrySq3BD0HLu5NX7bhp32CxxCL6DJalvvkc4PjuCCXT0pOHImis4SavCpPA5sZ
	UTNy5UEfqdQdSwoTKZqeQcnQ63niMeHSZCzcpVEfTk8gsI2X5gYNOtUhHpH7cmuGiqOw
	bxcQJQLG/nrOWSD3m7mVLJV7J62z/0P+I8WmwzHERJ+kPILNwTkoCkbXWmqm/3LYNpo6
	aGOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:from:to:references:message-id:date
	:user-agent:mime-version:in-reply-to:content-language
	:content-transfer-encoding;
	bh=SOyhymQ+MXZ1OVxbmcenwDvey6qX31Hw6SKF8Sl2fIk=;
	b=IziWXv4aGIjzCavmh3FWmLK48KnzTb2olNrEQX0z0CKt6AV13kxclNTCjAUrFmmI/Q
	d9u1IVg9lA1ZKV0gVcJDuBMyJoOZjqsBHkA9hb7xPZlUslZOSY55nzE7jpu+WfD19gCP
	QO6cL2l6X4gngEMiVJXK0g+vCK6THtgRhKiq70VhwDxIh7R8lmNfFqLncsMWN1HybjTU
	mjAHgG+FwFVPRG4wJyA/7Ydou5FKiA2wbq0HvuwNeNBJXdk6vGo2guGq4dpjIvsxWTa7
	MxA3bV9tl/BOW+ceI47WJyLYRDNLnIww9O682ceyf6E0QY0oXI5bL43Xzc1kszv9+3TT
	NrgQ==
X-Gm-Message-State: AODbwcAOnc6jytEfrkPfgqK4lWz4TwriJmyTFedjbNVFSnpOU8NYqmDK
	dacd6tX5abAzj/x900s=
X-Received: by 10.237.32.45 with SMTP id 42mr13825473qta.170.1497114253819;
	Sat, 10 Jun 2017 10:04:13 -0700 (PDT)
Received: from [192.168.1.101] (ool-45726efb.dyn.optonline.net.
	[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
	m29sm3214212qta.66.2017.06.10.10.04.11
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 10 Jun 2017 10:04:11 -0700 (PDT)
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
Message-ID: <83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
Date: Sat, 10 Jun 2017 13:04:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [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: Sat, 10 Jun 2017 17:04:17 -0000

Hi everyone,

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.

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

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


On-List Objection Summary
---------------------------

In general, they were:

* 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) 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.

If I missed any objections, I hope someone will point them out.


Off-List / Three Points of Ongoing Confusion
---------------------------------------------

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

1. Speed

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=3 months, and only x=1 withdrawal can make
forward progress [on the mainchain] at a time, and only x=1 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?".

Imho, replies of this kind disregard the effect of atomic cross-chain
swaps, which are instant.

( In addition, while side-to-main transfers are slow, main-to-side
transfers are quite fast, x~=10 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. )

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.


2. Security

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

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

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.

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

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.

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.

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

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.


3. Antifragility

There is an absolutely crucial distinction of "layers", which is often
overlooked. Which is a shame, because its importance really cannot be
understated.

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

By this, I mean there is an absolutely crucial distinction between:

1. A problem with a sidechain that negatively impacts its parent chain.
2. A problem with a sidechain that only impacts the sidechain users.

The first type of problem is unacceptable, but the second type of
problem is actually _desirable_.

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

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.

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.


Another Objection
------------------

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

One simple step would be to cap the quantity of BTC that can be moved to
each sidechain, (at x=10% ? aka 210,000).

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 = 6.85% of the total BTC were assumed to be
stolen).

I look forward to the continued feedback! Thank you all very much!

Paul

[1]
https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60


On 5/22/2017 2:17 AM, Paul Sztorc wrote:
> Dear list,
> 
> I've been working on "drivechain", a sidechain enabling technology, for
> some time.
> 
> * 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
> 
> 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!
> 
> 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.
> 
> 
> Scaling Implications
> ---------------------
> 
> 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.
> 
> 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.
> 
> 
> Total Transaction Fees in the Far Future
> -----------------------------------------
> 
> 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.
> 
> 
> Juxtaposition with a recent "Scaling Compromise"
> -------------------------------------------------
> 
> 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).
> 
> 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.
> 
> 
> Other Thoughts
> ---------------
> 
> 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.
> 
> 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.)
> 
> Cheers,
> Paul
> 
> [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=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
>