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 81C54721 for ; Tue, 30 May 2017 05:11:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68102134 for ; Tue, 30 May 2017 05:11:53 +0000 (UTC) Received: by mail-qk0-f180.google.com with SMTP id u75so60401133qka.3 for ; Mon, 29 May 2017 22:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VP8oL4NMXcBH74z47nh78hm5maosUFBe5uAPiBMF+1I=; b=LJUckw3ZJQ+Gew3Dg3nu2evI/K/W1W0j7WNqlDXt6amQtIVqunwH/tq23y+oSy9Z+h j39pe05p0j27CDzZWV3/fM5tj9npeiKQ2guwETFrUUuUnbonkAE0tpByjnnj5ilWSe2I zCitobomTLnE9gfcYeTz3OR80BcJohOf0PmzWkd0wrgJpIN0jlInGLfajyD2eUUeAzyn DsG3l9BqtQsy/JBHugslDPW6zA+mJBwTRygjmygnEhEQS2yw+EAX+GWBkao8m9QEvaF9 wfFvs1VKArQiH7deRPp9p4D2LBejAJPZwsF7j1A5s38DLp24jr23eMXlcm4yOwVPvLAf 1zlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VP8oL4NMXcBH74z47nh78hm5maosUFBe5uAPiBMF+1I=; b=KFvC9kmxa8N1Kz+Q3O53IzVySXmxScznaCRPHndi/Lvts9HpaZ//QaIQyEIfTxgrvq RyytJytOQNtyqauXdjpLJUYfhn+XKWPqqg+vG5B6q/nDyfMgRqiwS7TpW9ac0cBzf/Kg Q94iz1tKx3WA8oLABhlPKU5nhPagbsKTb02xC16iD9pigqpFEZGMRyqoMMfJlfyherRu QFPMoProV0x5QwUtr2RQFFdG+NPxjp5SPufu6GK28GAdmdWJEuZiCComL1tm+xy24XUG TLbFp/wX79ZJQbCPbTkdNkQKodJyfexMutSxSZ7U+QXSf+dJb+d5aaKkbe00lCGn+Eu8 kk5Q== X-Gm-Message-State: AODbwcB8DstRFPwOhdk/SXOxNckhz/++coGCol9SKXQAI/v4t1SuYi9z zbwaZpIpXL6rJBX4HldwXA== X-Received: by 10.55.42.212 with SMTP id q81mr19023109qkq.228.1496121112122; Mon, 29 May 2017 22:11:52 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id t35sm7766117qta.62.2017.05.29.22.11.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 22:11:50 -0700 (PDT) To: Peter Todd References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <20170522133335.GA17194@fedora-23-dvm> <20170528210757.GA19450@fedora-23-dvm> From: Paul Sztorc Message-ID: Date: Tue, 30 May 2017 01:11:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170528210757.GA19450@fedora-23-dvm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion 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: Tue, 30 May 2017 05:11:54 -0000 Hi Peter, Responses below. On 5/28/2017 5:07 PM, Peter Todd wrote: > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote: >> Surprisingly, this requirement (or, more precisely, this incentive) does >> not effect miners relative to each other. The incentive to upgrade is only >> for the purpose of preventing a "theft" -- defined as: an improper >> withdrawal from a sidechain. It is not about miner revenues or the ability >> to mine generally (or conduct BMM specifically). The costs of such a theft >> (decrease in market price, decrease in future transaction fee levels) would >> be shared collectively by all future miners. Therefore, it would have no >> effect on miners relative to each other. > > That's not at all true. If I'm a miner with a better capability than another > miner to prevent that theft, I have reasons to induce it to happen to give me > political cover to pushing that other miner off the network. Miners can abstain from 'voting', which is politically neutral. Or, if they wish, smaller miners could acquiesce to the coercion and just copy the votes of the attacking 51% group. For users who are only running Bitcoin Core, there is nothing bad about that. As you say, a 51% group can arbitrarily start orphaning the blocks that are mined by non-member rivals. This _may_ be a problem, or it may not, but it is not exacerbated by drivechain. So, what exactly is "not at all true"? > > This is a very similar problem to what we had with zeroconf double-spending, > where entities such as Coinbase tried to pay off miners to guarantee something > that wasn't possible in a geninely decrentralized system: safe zeroconf > transactions. I don't see what you mean here. You can't stop Coinbase from donating BTC to a subset of miners. That will always be possible, and it has nothing to do with drivechain (as I see it). > >> Moreover, miners have other recourse if they are unable to run the node. >> They can adopt a policy of simply rejecting ("downvoting") any withdrawals >> that they don't understand. This would pause the withdraw process until >> enough miners understand enough of what is going on to proceed with it. > > Why are you forcing miners to run this code at all? Could we not say the same thing about the code behind CLTV? The nature of a contract, is that people are happier to be bound by some rules that they themselves construct (for example, a nuclear non-proliferation treaty). In this case, miners prefer sidechains to exist (as existence makes the BTC they mine more valuable, and provides additional tx fee revenues), and so they would like to run code which makes them possible. > > Equally, you're opening up miners to huge political risks, as rejecting all > withdrawals is preventing users' from getting their money, which gives other > miners a rational for kicking those miners off of Bitcoin entirely. As I explained above, miners can abstain from voting, which is politically neutral, or else they can delegate their vote to an aggressive miner. The "51% can orphan" concern could be raised, even in a world without drivechain. All that is required, is for the miners to be anonymous, or in private 'dark' pools (and to thereby escape censure). But there is a much bigger issue here, which is that our threat models are different. As you may know, my threat model [1] does not include miners "pushing each other off". It only cares about the miner-experience, to the extent that it impacts the user-experience. Moreover, I reject [2] the premise that we can even measure "miner centralization", or even that such a concept exists. If someone has a definition of this concept, which is both measurable and useful, I would be interested to read it. ( For what it's worth, Satoshi did not care about this, either. For example: "If a greedy attacker is able to assemble more CPU power than all the honest nodes, he...ought to find it more profitable to play by the rules." which implies robustness to 51% owned by one entity. ) [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/ [2] http://www.truthcoin.info/blog/mirage-miner-centralization/ > >> Finally, the point in dispute is a single, infrequent, true/false question. >> So miners may resort to semi-trusted methods to supplement their decision. >> In other words, they can just ask people they trust, if the withdrawal is >> correct or not. It is up to users to decide if they are comfortable with >> these risks, if/when they decide to deposit to a sidechain. > > Why do you think this will be infrequent? Miners with a better ability to > validate the drivechain have every reason to make these events more frequent. It is part of the spec. These timing parameters must be agreed upon when the sidechain is added, ie _before_ users deposit to the sidechain. Once the sidechain is created, the timing is enforced by nodes, the same as with any other protocol rules. Miner-validation-ability has no effect on the frequency. > >> It is a matter of comparing the costs and benefits. Ignoring theft, the >> costs are near-zero, and the benefits are >0. Specifically, they are: a >> higher BTC price and greater transaction fees. Theft is discouraged by >> attempting to tie a theft to a loss of confidence in the miners, as >> described in the spec/website. >> In general the incentives are very similar to those of Bitcoin itself. > > This is also a very dubious security model - I would argue that Bitcoin is much > *more* valuable if miners do everything they can to ensure that drivechains > fail, given the huge risks involved. I don't see how. Users are free to ignore the sidechain, so it can only benefit them. Fortunately for you, if that is actually what miners believe, then there will be no problem, as miners will just filter out drivechains (so that Bitcoin will be "much *more* valuable"), which they can easily do. > I would also argue that users should do > user-activated-soft-forks to ensure they fail. Again, I don't think that kind of UASF can succeed, because one option strictly dominates the other. But the users get the final say, of course. Empirically, I have observed overwhelming support for sidechains among users, business, and other developers. The btc-investors I spoke to were all very excited about the prospect of sidechains, even more so than they were excited about SegWit. > > By comparison, note Adam Back and my own efforts to ensure miners have a > smaller part in the ecosystem, with things like committed (encrypted) > transactions and my closed-seal-set/truth-list approach(1). We want to involve > miners as little as possible in the consensus, not more. I agree that miners should have as little influence as possible (and they probably agree, as well). But a 51% group can filter any message they like from the blockchain. For sidechains, there will need to be two public networks, so concealment is not an option. And, I repeat, for regular users of Bitcoin Core, drivechain does not make a 51% group more dangerous than they already are. Moreover, there are cases [1] where miner-involvement can make a big _positive_ impact. Just as it can be beneficial (essential, in fact) for Bitcoin to filter out harmful interactions among txns (in other words, good for miners to filter out double spends), I have discovered situations where it is beneficial and essential for miners to filter out harmful interactions among multiple chains. So I think I am actually hitting the "as little as possible" target. [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts > > I have to ask: What use-cases do you actually see for drivechains? Why can't Here is a tentative project list: http://www.drivechain.info/projects/index.html And, as I say on the FAQ, "If each individual user is free to sell his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny users the opportunity to move their money between two sidechains." So, in a strong way, the entire altcoin market makes the case for a usefulness of sidechains. Bitcoin is a form of money, and only one form of money can exist per currency area. So, if Bitcoin is not the winner, it will eventually cease to exist altogether. Altcoin-competition is an existential threat to Bitcoin, one which is far more relevant than anything you've presented so far. Secondly, one important value of permissionless innovation is that one doesn't really know, today, what cool ideas other people are going to come up with tomorrow. If you did, they'd be today's ideas. Third, Core's review process has two opposite problems: on one hand it is slow and grueling, and on the other it is fraught with the possibility of catastrophic error. It would be better, for everyone, to allow people to try their own (non-aggressive) experiments, and to make their own mistakes. Already, I have seen the review process abused to create/maintain fiefdoms of expertise, so that the abusers can extract money from clients/employers/VCs. Just think of all of the free time you would have, Peter, if you didn't have to spend it all reviewing these projects! > those use-cases be done in the much safer client-side validation fashion? ? How is drivechain _not_ within the category of client-side validation? With BMM, validation is only performed by those users ("clients") who opt-in to the new features. The economic model of BMM is directly comparable to that of Bitcoin's PoW -- the highest-bid chain should be the healthiest one. Can you post the Github link for your most up-to-date client-side validation work so that we can compare the safety and other features? Thanks, Paul > > 1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy >