path: root/40/236353d388aedaf4e78172c7f0d8513673b45b

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
>