Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38B48BC9 for ; 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 ; 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 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: References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com> To: Paul Sztorc 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/ = [2] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.h= tml = -- 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 = > 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 ) 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 = ). >=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 = >=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
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-s= urveillance-research/

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju= ne/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> wrote:

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

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

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=3D10% ? 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 =3D 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/c4beef5c2a= a8e52d2c1e11de7c044528bbde6c60


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=3DYErLEuOi3xU&list=3DPLw8-6= ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=3D4

_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --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--