From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 412A192B for ; 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 ; Sat, 10 Jun 2017 17:04:15 +0000 (UTC) Received: by mail-qt0-f179.google.com with SMTP id w1so97792423qtg.2 for ; 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 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jun 2017 10:04:11 -0700 (PDT) From: Paul Sztorc To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >