path: root/fc/4fdda4373f5dbaaaaff5ddef6a9327252ba203

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 A6C17C0F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Dec 2017 22:16:50 +0000 (UTC)
Received: by mail-qt0-f176.google.com with SMTP id k19so1084964qtj.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <ZmnSCPxj@protonmail.com>, Chris Stewart <chris@suredbits.com>
References: <d3497397-33c3-90c1-1be8-a733736eac0b@gmail.com>
	<1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com>
	<dd2781a6-3e10-9f0c-6ee0-a2c070b7cf67@gmail.com>
	<CAB+qUq4wNv=-ZSibUvVCwYSE7Qw8xe8EH91KG6znUp1d7X=mdA@mail.gmail.com>
	<CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com>
	<b0c3f0f9-72f4-b73e-f5b1-e5590f9456aa@gmail.com>
	<4iTYKa7LCe7_wN9neyumkheFrN7lPcmE8tbeD8if5SiobaBCeJUb3jpkwwrxi2-lL6q67TPLEAef43c7w-BRoFs21PUzUK8EOyTgaPCUZpA=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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, 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