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 A6C17C0F for ; Tue, 12 Dec 2017 22:16:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 957C51A6 for ; Tue, 12 Dec 2017 22:16:50 +0000 (UTC) Received: by mail-qt0-f176.google.com with SMTP id k19so1084964qtj.6 for ; Tue, 12 Dec 2017 14:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=klq10UwKZa3eYLwMSfgZAVEZxnbquXACvZA2QvKow2I=; b=epqHR4nx1vZOnXSsyCsPsasTpP78tiR9aPIgQQggCn7Q4fYWPGky/191aT9M69eGJI WPV8HE6xnXitCa5qEuZh7HJHhliDS61ttRhQdYumu1dc7bU2qdberiFOpwfPolfwir7h eNNAD7Vk+U+gYLhS1xqCGIi8oJhe9M7QMrn5kTuFboMgc1OysQHvrTJkbVMGOySgJz14 gDGiZDCh3gRz1aIHfTXq3Uu24GxOZZBU78EUYXT/f6U9vzAUrH6GqkRhMRz83dKflUOP BiMxoECTAY0PO+y5LPcgGjO2oG6vh5HSTcGVz1yQv2bEWsYDN+nNW/cMPgMFo4+7L25V A0rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=klq10UwKZa3eYLwMSfgZAVEZxnbquXACvZA2QvKow2I=; b=gVd7pHeCee9kCd4BuW33kfQ3aDTo0B/bFu9RqHoh3y0ZK9GXXWykbpnqQepnZpkzhS DlDkX8PnJSPYgujVDX6Q1Q/Og+ZMOePJpqPalF2wvxRP5bWIVAe4j/hcU0wZDJVK2RuG mPquWwa0hwevQ6KKzSvcZYorF84zMGifdGqIbaUpak6rrXhihXB6qmw8i54no0FuxjFD 4UHgCwg8GVyjcm+IkKpAuc/dqBtCBJ8bWiIfGqLFNN3weNnVxE59sqvs1OmJcgXIwQRM tVc0U2tln5Dh5spcFmLpe6ECA7ibpX6cFP/zt2O32xTMpRWur84K8e1hoLnWV1E/Ahdr BqAw== X-Gm-Message-State: AKGB3mLQhAFB6YVgkpDcsb/ch5aU6meS/luS2yfkKKPmk7I663lXeDJz HeYv7VbsX8PPA9ORbxn1ti5ozQ== X-Google-Smtp-Source: ACJfBovac/Oqj3yNXVm2VYVrz4q0NHs0Gw4KpD5tK8LYa8yZrS08PB8c5C0BjMXri2fDoCEUrfeVxA== X-Received: by 10.200.51.143 with SMTP id c15mr8061302qtb.46.1513117009076; Tue, 12 Dec 2017 14:16:49 -0800 (PST) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id q13sm148599qta.22.2017.12.12.14.16.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 14:16:47 -0800 (PST) To: ZmnSCPxj , Chris Stewart References: <1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com> <4iTYKa7LCe7_wN9neyumkheFrN7lPcmE8tbeD8if5SiobaBCeJUb3jpkwwrxi2-lL6q67TPLEAef43c7w-BRoFs21PUzUK8EOyTgaPCUZpA=@protonmail.com> From: Paul Sztorc Message-ID: <3ed6b08f-b0c8-a469-9ef3-4edebce3c687@gmail.com> Date: Tue, 12 Dec 2017 17:16:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <4iTYKa7LCe7_wN9neyumkheFrN7lPcmE8tbeD8if5SiobaBCeJUb3jpkwwrxi2-lL6q67TPLEAef43c7w-BRoFs21PUzUK8EOyTgaPCUZpA=@protonmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Two Drivechain BIPs 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, 12 Dec 2017 22:16:51 -0000 Hello ZmnSCPxj, Thanks for contributing your thoughts. I wish I were able to respond soon= er! 1. I'm a little confused about the second half of your message, and its emphasis on pools. As you know, pools can be created or destroyed an unbounded number of times, costing only a small time lag. So I do not see why anyone would care about pool-death (except for the administrator of the pool of course -- and this exception is, itself, strong evidence that pools will reflect the interests of their members). Pools are just some naturally-occurring phenomenon that arise when many different hashers all want similar things. 2. You have quoted a section where I suppose that miners are offering an 'atomic swaps' service. And you usually talk about that hypothetical scenario I've outlined. But sometimes you talk in a way that leads me to believe that you have departed from that hypothetical. For example you talk about frozen withdrawals, invalid withdrawals, and miner-to-user harm. But that isn't possible in my hypothetical, because users can escape all of those things by using atomic swaps (which, recall are instant and competitively priced, see #4). Moreover, miners can pretend to be users (for the purpose of using these atomic swaps). If you want to talk about a world where users aren't using these swaps, I would appreciate it if you were more clear. 3. The question of miners harassing each other using strategy is a very interesting one. First, (as you seem to know) the withdrawals are designed to be combine-able. This is in fact not only the default behavior but also the most efficient behavior. (Assuming that n quantity of economic transfers must go across, it is of course best to do them in one transaction.) So, your complaint must immediately be limited to the case of "spiteful" miners who care more about blocking opponent's transfers (for whatever reason) than they care about upvoting their own transfers. However, if any miner pursues a spiteful strategy, the victim(s) can respond by orphaning. For example, if 33% are producing 'spiteful blocks', the other 66% can easily orphan these. The central issues, as I see it, is that to be *spiteful* is also to be *different* and *noticeable*. Thus, different blocks can be orphaned. Some may worry that this opens the door to endless vindictive arbitrary orphaning (and that this is either the reason that such an alternative will not work and therefore not be persuasive, or else that the outcome of endless arbitrary orphaning would itself be a bad one). My view (and observation) is that the threat of eventual orphaning is sufficient, and that therefore there will be no actual orphaning. This is because the antagonizing 33% group is now its own victim group, and they now have an overwhelming incentive to either [a] stop being different (in this case, spiteful), or else to [b] quickly obtain an additional 18% hashrate so as to survive the orphaning. Should they add 18% to their 33%, "they" will have 51%, and we might wonder if they will try orphaning of their own. However, if they do, it merely restarts the above logic, with the 49% fighting to persuade a critical 2% to join. So far, this logic may terminate with two 50% pools that each stubbornly refuse to interact. But eventually chance will one of their blockchains ahead of the other's, and the members of the disfavored group will feel pressure to defect (or else they are likely to be left behind). It is no different from traditional miner-bitterness over having not found the most-recent block. Users who move side-to-main via atomic swaps will have no reason to care about any of this.=C2=A0 4. As I point out in the Nov 2015 specification and security model, and as you have suggested, the atomic swaps will only be ultra-cheap and ultra-available if there exists *some other way* of *eventually* moving side-to-main with *certainty*. The goal is to have a side-to-main method that definitely will work, even if it takes a very long time to work. Then the atomic swap is paying a premium for speed only, relative to this method. This is why the security model of drivechain relies (partially) on investor disappointment that sidechains are no longer going to be supported. And it is why the slow (non-AtomicSwap) withdrawal process is so slow and delay-able in the first place -- to increase its security. If it is secure enough to withstand any attack, then attackers will eventually give up (or else, they will never attack in the first place). This satisfies the criterion of an alternative withdrawal process that is certain and eventual. Paul On 12/7/2017 2:28 AM, ZmnSCPxj wrote: > Good morning Paul and Chris, > > >I don't agree with the conclusion (that the optimal policy is "always > downvoting", see above), but even if this analysis turns out to be > correct, it isn't a total disaster. The result (which is in the > original Nov > >2015 specification) is that miners are the ones who perform the > atomic swaps. Then they walk the coins side-to-main (which, at this > point, are *their* coins). As long as there are a few large mining > groups, > >competition will drive the atomic swap fees down to negligible levels.= > > Assuming there are three large mining groups who will ruthlessly want > to undercut their competition, and with roughly 33% of total hashpower > each (with the remaining 1% being some negligible hoi polloi), then > one strategy to undercut your competitors would be to upvote only your > own withdrawals and downvote that of your competitors.=C2=A0 A miner us= ing > this strategy hopes that the other miners will give up on withdrawing > their own coin and trade their sidecoins at a discount to the > undercutting miner.=C2=A0 That is, it is a hostage attempt of the sidec= oin > funds of the other miners. > > In the case of three large mining pools that mistrust one another, > then, no withdrawal would ever push through and drivechains stabilize > to one-way pegs. > > Now suppose that two of the mining pools collude.=C2=A0 They join their= > withdrawals into a single withdrawal proposal and upvote that, while > downvoting the withdrawal of the third miner.=C2=A0 I observe that this= is > an opposite disaster: the 66% colluding miners can instead decide to > simply outright make an invalid withdrawal of all funds, split up in > half between themselves. > > -- > > But three exactly equal mining pools is unnatural, for that matter > > Suppose that there are three mining pools: A with 34%, B with 33%, C > with 32%, and the hoi polloi making up the remaining 1%.=C2=A0 Those th= ree > pools cannot safely let the others withdraw funds. > > Suppose A colludes with C to join their withdrawal proposals and their > hashpower to withdraw.=C2=A0 This means that B can be pressured to sell= its > sidecoins for a discount to the joint coalition of A and C, since B > cannot withdraw its own coins.=C2=A0 This lowers the profitability of B= , > causing grinders to leave them in favor of either A or C.=C2=A0 Since A= is > slightly larger than C, it is slightly more preferable, so it grows in > size slightly more than C does.=C2=A0 Eventually B dies due to the > coalition of A and C.=C2=A0 A and C are the only remaining pools, with = A > slightly larger than C.=C2=A0 In this case, A can break from the coalit= ion > and squeeze C of its sidecoins, since only A can withdraw (as it has > more hashpower than C).=C2=A0 Again, grinders will leave C for A.=C2=A0= A > rational C that is capable of considering this possible future path > will thus never ally with A in a coalition to crush B, as it will then > be next in line for being destroyed. > > Similar analyses for coalitions of (B, C) and (A, B). > > Knowing this, and knowing that they will end up sidecoin bagholders if > they cannot withdraw coins, all miners decide to collude together and > put all their withdrawals into a single withdrawal proposal.=C2=A0 But = this > removes any check-and-balance that the single withdrawal proposal is > truthful to the sidechain: that is, the single coalition of A,B, and C > can decide to just steal all sidechain funds and reassign them in > proportion to their hashpower.=C2=A0 This might be stable at end-of-lif= e > for the sidechain where all ordinary users of the sidechain have > exited it, but is otherwise a theft risk if the sidechain is operating > normally. > > Regards, > ZmnSCPxj