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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C52FFBF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Mar 2016 20:54:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
[209.85.192.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F137116
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Mar 2016 20:54:20 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id w128so21656736pfb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Mar 2016 12:54:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:references:in-reply-to;
bh=dWjaTS9GTrI5s9HhWQPhF2Rt9mgvNKov/9VYytzA4I8=;
b=BiCh8TCa33kR7wZUO/u/osK3OnpKRQaQLTQ/F8Q/FoeEVonLH2gVDRUAtpQewLUH2Y
XdvA1a76nSueO0NPY1X901OvP76Oy63+bsCZnNFGGukuJK7u9WAT07kIoBRSsIkK/7Mb
guhwgJ/1cdQf5lLQjl4QlRWdFEGwbJqz6pHBiywx1hnMYINz1QD7Ci9bCepTQCw9bOlL
pn7oI+8nVFH13pdyjTURPSlKb/dOSz36ByqnYglgtn/JqWjikiZDhcjGH63Uv6Nl2nJO
08/wMnGptBRFfI+kjoucKEsUFxTrg2gHrTFxJkFY6f3n1zxc8sTxFveNZkoMwWTTfELb
d++A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to;
bh=dWjaTS9GTrI5s9HhWQPhF2Rt9mgvNKov/9VYytzA4I8=;
b=Pt+5a4Y1AJprHwxGJ5TAfGM3fF2V5Eu9B2fFY8zQyNMd/4XiLsMHUXdGhcAR9vDJVf
p4PdNsSjNjZlwWIjSe/6hKUPTQdLDPGeSULwa1ycoV+i0VL11Vc/KOEUObA9nYAT3XQN
1IbrUZRgR3297T9xqRVcC2qkyN3LLKorBATDOT1thoHCb4PGznlLmTHLhWmiWRCM8ZGb
XrU+/HD15NYdY13CTtNUkUxOvshm3IJ7G4t8mu8ZIJcIItAxRWVPUlhjWJ8UlE7ek0He
Vepd5qiRKx9PqKw1M7DGaNX8BkFfV8f2jwAMlsvG6QHX80s6Vz5TQIwq2Zkf8R2gJQUj
r5/Q==
X-Gm-Message-State: AD7BkJIuzOVck7aAbAgNzpt1DLqRmFnZDff/WOx6ujXU96TcE2xQYU1BoTaMaBF6QorifQ==
X-Received: by 10.98.15.145 with SMTP id 17mr6557749pfp.19.1457038459793;
Thu, 03 Mar 2016 12:54:19 -0800 (PST)
Received: from ?IPv6:2601:600:9001:8060:6d45:92a3:b81f:95d7?
([2601:600:9001:8060:6d45:92a3:b81f:95d7])
by smtp.googlemail.com with ESMTPSA id
r87sm214681pfa.61.2016.03.03.12.54.18
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 03 Mar 2016 12:54:18 -0800 (PST)
Message-ID: <56D8A480.6040604@voskuil.org>
Date: Thu, 03 Mar 2016 12:54:24 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>
References: <201603021456.15820.luke@dashjr.org>
<201603021542.29609.luke@dashjr.org> <56D71488.4080607@gmail.com>
<CAE-z3OWA0sn+=+qqs8BtiBe7T9Qdb4G8XAS_bX4hScq225iZQQ@mail.gmail.com>
<00e101d174b5$f2659060$d730b120$@voskuil.org>
<20160302230213.GA888@muck>
In-Reply-To: <20160302230213.GA888@muck>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="9IWvuxiwShosKoqIbk1wqMjT0aLP5xFk0"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Thu, 03 Mar 2016 21:01:37 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 03 Mar 2016 20:54:20 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9IWvuxiwShosKoqIbk1wqMjT0aLP5xFk0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 03/02/2016 03:02 PM, Peter Todd wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev =
wrote:
>>> A 6 month investment with 3 months on the high subsidy and 3 months o=
n low subsidy would not be made=E2=80=A6
>>
>> Yes, this is the essential point. All capital investments are made bas=
ed on expectations of future returns. To the extent that futures are perf=
ectly knowable, they can be perfectly factored in. This is why inflation =
in Bitcoin is not a tax, it=E2=80=99s a cost. These step functions are ma=
de continuous by their predictability, removing that predictability will =
make them -- unpredictable.
>=20
> You know, I do agree with you.
>=20
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can chang=
e
> any rule currently in Bitcoin.
>=20
> It'd be perfectly reasonable to create an altcoin with a 22-million-coi=
n
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same=
> UTXO set as Bitcoin as a means of initial coin distribution.
>=20
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those=
> coins. We may choose not to, but if 95% of the hashing power decides to=
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>=20
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>=20
I agree, this is a perfectly rational interpretation. I also agree that
this particular instance is academic. But I see more to this than
accepting what is possible.
In the case of Federal Reserve Notes the gold obligation was abrogated.
This was (at least) a contract default, implemented by force of arms.
This contentious hard fork was clearly an attack.
But in a system with no authority and in which nobody has formed a
contractual obligation with anyone else, what would constitute an attack
on the money? There is no difference between state attacks on (or
collusion with) miners and miners acting on self interest.
One answer is that nothing is an attack, it's up to the market to
decide. But to the extent that there can be an attack on the money, the
attempt to move the value of the coin to an altcoin (hard fork) is it.
Though the choice of the term "attack" isn't essential.
The importance of recognizing an attack is that it affords one the
opportunity to defend against it. People holding "dollars" in 1933 were
ill equipped to defend against a system level attack (monetary policy),
in part because many did not recognize it as such, and in part because
there was insufficient preparation by those who did.
I see us building the tools and awareness necessary for defense. As you
say, nobody has to buy into an altcoin forked from their coin. This much
is simple to achieve. The more difficult problem is preserving the
utility of the original coin. Clearly the purpose of a hard fork (as
opposed to a new coin) is to transfer this value.
We've all seen arguments for contentious hard fork deployment that
explicitly depend on the fear of monetary loss to drag people to
acceptance. While this may be the nature of the technology, it's
important that we develop effective defense against it.
Ultimately the only defense is individual validation. The collusion of
banks (web wallets) with miners in attacking consensus is obvious. But
even without active collusion, the surrender of validation leaves people
just as defenseless as *being* unarmed while retaining a right to
*become* armed.
Even if every person mines at the same level, the system amounts to
little more than majority rule if validation is not decentralized. There
are people perfectly willing to exploit this weakness.
e
--9IWvuxiwShosKoqIbk1wqMjT0aLP5xFk0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJW2KSAAAoJEDzYwH8LXOFOWjcH/3Wq2YHtdoxlyvBVgaXCSmzd
uMQu9wQn4Hv/3845WhgoLpHfFS/UZie/FzyB5IVcGOu/Qt0SrMxrj6aOMoX24WtL
BPjo72Z56C9sOYV4tmS0anzQzw9D4CNgSYbCX8hX2IvCSELRBj2H9A4FIIrCzuoo
YIMvlUmHVDy5qegALlLuBUojZBPz62Sbt/Gf2mmdx+sp8ku76YgxjZr3WCpBral2
wGrPRI0nuXYlU8HCO7DR0zhrd9UjiMbcb3yYH84CnEbtsRfebHXe4tVy0AmI183y
I9E8O/ehBwBg78IHYMIEJcR86tNFoF4zXeuZcoeNdyQDuwEogWuj0E+xAr2AEyo=
=sOUl
-----END PGP SIGNATURE-----
--9IWvuxiwShosKoqIbk1wqMjT0aLP5xFk0--
|
