1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F2222C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2017 21:22:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148095.authsmtp.com (outmail148095.authsmtp.com
[62.13.148.95])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6CBA915B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2017 21:22:57 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v4SLMsUb075929;
Sun, 28 May 2017 22:22:54 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v4SLMqlo084629
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 28 May 2017 22:22:53 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 91933400B5;
Sun, 28 May 2017 21:22:51 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 1E0EB20611; Sun, 28 May 2017 17:07:57 -0400 (EDT)
Date: Sun, 28 May 2017 17:07:57 -0400
From: Peter Todd <pete@petertodd.org>
To: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <20170528210757.GA19450@fedora-23-dvm>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<20170522133335.GA17194@fedora-23-dvm>
<CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC"
Content-Disposition: inline
In-Reply-To: <CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: cf957064-43eb-11e7-829f-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAoUFVQNAgsB AmEbWVZeUl97XGA7 bghPaBtcak9QXgdq
T0pMXVMcUgELfWFA WkEeWh10dQwIeX5z YUAsDSZSWUN6c0Jg
Rk0BR3AHZDJndWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYAhP Qx8AJlIbQEBDW3t0 fR0bADg0AQULQD97
Ax09IUMHB0cWNC0A
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham 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: Sun, 28 May 2017 21:22:58 -0000
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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) wou=
ld
> 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.
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 someth=
ing
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.
> 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?
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.
> Finally, the point in dispute is a single, infrequent, true/false questio=
n.
> 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 frequen=
t.
> 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 would also argue that users should do
user-activated-soft-forks to ensure they fail.
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 invo=
lve
miners as little as possible in the consensus, not more.
I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZKzwoAAoJECSBQD2l8JH7gXsH/izPCiggfqdQApm0k7Jnnq7U
4F73orCoTEPwR/bK28Uj5PODQfXjGKhD+DHJN3kRmZXOwhiPaxRFTWmVFFFjEDVk
jovvPMOSeWqqR2pyNe7I/FRu6oayHsEiDzczlaEfAs5mk8AMz7tseLOJ+pXgeLBr
eqGyVSx6ULKjp0bkmJPBJtoDdhdQ3AS7y1muit17JwRtdYRNS6NaFaMSTDBjfp9C
dEct5DXW8NXP1Xqo+Wm+g0YwhRVbXdMTQtFfVg03xno3w9kbw41lWyT2IPbDHy1+
sFKuzcgHdiWfLhe5QscMXlC1ROpil0E6JNXsLxru83cNoeMkUVnHygf+TfEJAX0=
=CGAV
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
|
