diff options
| author | Paul Sztorc <truthcoin@gmail.com> | 2017-05-30 01:11:51 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-30 05:11:54 +0000 |
| commit | 6b7c12109ef43b5b5de20cb1ec2e4e39573b6be9 (patch) | |
| tree | abd402e2e526c0f52817759a62a46b208b5fdb6c | |
| parent | b488c5c8828148f80691c35f7e66475e740c1207 (diff) | |
| download | pi-bitcoindev-6b7c12109ef43b5b5de20cb1ec2e4e39573b6be9.tar.gz pi-bitcoindev-6b7c12109ef43b5b5de20cb1ec2e4e39573b6be9.zip | |
Re: [bitcoin-dev] Drivechain -- Request for Discussion
| -rw-r--r-- | 40/236353d388aedaf4e78172c7f0d8513673b45b | 298 |
1 files changed, 298 insertions, 0 deletions
diff --git a/40/236353d388aedaf4e78172c7f0d8513673b45b b/40/236353d388aedaf4e78172c7f0d8513673b45b new file mode 100644 index 000000000..3c16483ac --- /dev/null +++ b/40/236353d388aedaf4e78172c7f0d8513673b45b @@ -0,0 +1,298 @@ +Return-Path: <truthcoin@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 81C54721 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 30 May 2017 05:11:53 +0000 (UTC) +Received: by mail-qk0-f180.google.com with SMTP id u75so60401133qka.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <pete@petertodd.org> +References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> + <20170522133335.GA17194@fedora-23-dvm> + <CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com> + <20170528210757.GA19450@fedora-23-dvm> +From: Paul Sztorc <truthcoin@gmail.com> +Message-ID: <b04f8c13-9358-303d-2335-f509cafb90a5@gmail.com> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: 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 +> + |