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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B1756A55
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Mar 2016 05:11:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
[209.85.218.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94BE4196
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Mar 2016 05:11:17 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id m82so7973936oif.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 02 Mar 2016 21:11:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc; bh=GZT2KTMdC0yeJwmrbKkO+umPjpIj8bG2B+hSLiP19XQ=;
b=ZFeFip41c5j3m8RhNfFAKBIxy4mlLAO90XVW+MF3AmbxJkgcShvhhR3HFBhv2QXtnj
HNQVPuuOAfPBM1LZ2EqMi/e94cGQaJIazmiUZwm1k2VxdCx1ZfsUFv2IZeAuOMTOZ7b3
VjjpJLSBHCLiBqR7ckSVcyD/uxpaeSxn0mkzIqbL3TcOYACr8PotBMUG+g7kHixqv6Dh
ZFIK4JetJ+ogcCJEuffTAG9jkiMMgPgYrx6vsDsaxISlZhLlsgru9kOhvG41WdY818SR
XqqqYxEhvxRAvmRa8GnV4d0qVJZfctLvXc0nwsymMINFD4iE5Cok2I3NGyfm8UG0LsFS
BBdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=GZT2KTMdC0yeJwmrbKkO+umPjpIj8bG2B+hSLiP19XQ=;
b=A/xwk4IaZSWA+oH9XPDEh1771iU69k0y4UcwFf0gAcG7xzib2j4oHz/FyDzfyDXAPX
G7S+VIM2kjZyGutdEjSZaWI3lpXGCsgx7wSoDD+UmSG3fsHh0+XvN/t50thHraOqRbUY
0vraoQ7s2rOEXDDkFiz5uWQV0KxhxALSlVzHW2+Pt7b2+LVLumA+ULHVUznso4axvagb
9Z/ZBQx+CPOst6nqqf7oxw64t9ljHJ8lkbse4UO0dc5MkzbmdlDDndxpN3l3i6ItWIDh
DpLZErsHEpsger2Ecqa/bvaj/83vhtl7TP8ldJj3R2sv6WJ+QCh0VZMepPb5U1+nQ8QI
foJA==
X-Gm-Message-State: AD7BkJKW5sbcu1AjmNed7uLhWTe0b2W1KK3V2HDK16sydwszebwZbb20TO714xrU7MOOzuFS2LJNNzpKbbeLfQ==
MIME-Version: 1.0
X-Received: by 10.202.91.135 with SMTP id p129mr403862oib.19.1456981876891;
Wed, 02 Mar 2016 21:11:16 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.55.71 with HTTP; Wed, 2 Mar 2016 21:11:16 -0800 (PST)
In-Reply-To: <20160302230213.GA888@muck>
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>
Date: Wed, 2 Mar 2016 21:11:16 -0800
X-Google-Sender-Auth: 1W8KEjcjYz0GkEQfVyIac8aeHDg
Message-ID: <CAGLBAhcL+Z7uPVG6U5cEShc52KmkYFb6USF_gk6bZaj2SFv37A@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113d4b903769d3052d1e0737
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,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 15:02:05 +0000
Cc: Bitcoin Dev <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 05:11:18 -0000
--001a113d4b903769d3052d1e0737
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It makes sense to me that there might be objective conditions under which
we would want to use a number smaller than 2016. A good example would be a
mean time between blocks of more than 20 minutes over the last 144 blocks
(one - two days). If such an occurrence ever happened, and the software
then cut the retarget interval to 1008 (triggering an immediate retarget if
the counter is over 1008), the only problem I see is how to measure the
mean time between blocks.
In fact, has anyone examined the potential problems of reducing the
retarget period, even to one? Not Really.
<http://bitcoin.stackexchange.com/questions/9305/why-not-retarget-on-every-=
block>
That question includes a suggestion of retargeting on every block, but
using the same 2016 block window for the calculation, so difficulty changes
would be very smooth, and still as unpredictable and how long till we find
the next block.
On Wed, Mar 2, 2016 at 3:02 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 base=
d
> on expectations of future returns. To the extent that futures are perfect=
ly
> 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 made =
continuous
> by their predictability, removing that predictability will make them --
> unpredictable.
>
> You know, I do agree with you.
>
> 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 change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> 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.
>
> 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.
>
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000004d430e1daab776bc1c194589b0326924220faa00efc50cf
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--=20
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--001a113d4b903769d3052d1e0737
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>It makes sense to me that there might be objecti=
ve conditions under which we would want to use a number smaller than 2016.=
=C2=A0 A good example would be a mean time between blocks of more than 20 m=
inutes over the last 144 blocks (one=C2=A0 - two days).=C2=A0 If such an oc=
currence ever happened, and the software then cut the retarget interval to =
1008 (triggering an immediate retarget if the counter is over 1008), the on=
ly problem I see is how to measure the mean time between blocks.<br><br></d=
iv>In fact, has anyone examined the potential problems of reducing the reta=
rget period, even to one?=C2=A0 <a href=3D"http://bitcoin.stackexchange.com=
/questions/9305/why-not-retarget-on-every-block">Not Really.</a> That quest=
ion includes a suggestion of retargeting on every block, but using the same=
2016 block window for the calculation, so difficulty changes would be very=
smooth, and still as unpredictable and how long till we find the next bloc=
k.<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Wed, Mar 2, 2016 at 3:02 PM, Peter Todd via bitcoin-dev <span dir=3D"lt=
r"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">On Wed, Mar 02, 2016 at 11:01:36=
AM -0800, Eric Voskuil via bitcoin-dev wrote:<br>
> > A 6 month investment with 3 months on the high subsidy and 3 mont=
hs on low subsidy would not be made=E2=80=A6<br>
><br>
><br>
><br>
> Yes, this is the essential point. All capital investments are made bas=
ed on expectations of future returns. To the extent that futures are perfec=
tly knowable, they can be perfectly factored in. This is why inflation in B=
itcoin is not a tax, it=E2=80=99s a cost. These step functions are made con=
tinuous by their predictability, removing that predictability will make the=
m -- unpredictable.<br>
<br>
</span>You know, I do agree with you.<br>
<br>
But see, this is one of the reasons why we keep reminding people that<br>
strictly speaking a hardfork *is* an altcoin, and the altcoin can change<br=
>
any rule currently in Bitcoin.<br>
<br>
It'd be perfectly reasonable to create an altcoin with a 22-million-coi=
n<br>
limit and an inflation schedule that had smooth, rather than abrupt,<br>
drops. It'd also be reasonable to make that altcoin start with the same=
<br>
UTXO set as Bitcoin as a means of initial coin distribution.<br>
<br>
If miners choose to start mining that altcoin en-mass on the halving,<br>
all the more power to them. It's our choice whether or not we buy those=
<br>
coins. We may choose not to, but if 95% of the hashing power decides to<br>
go mine something different we have to accept that under our current<br>
chosen rules confirmations might take a long time.<br>
<br>
<br>
Of course, personally I agree with Gregory Maxwell: this is all fairly<br>
unlikely to happen, so the discussion is academic. But we'll see.<br>
<span class=3D""><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</span>000000000000000004d430e1daab776bc1c194589b0326924220faa00efc50cf<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr">I like to provide some work at no charge to pr=
ove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.l=
itmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.m=
emeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm th=
e webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">T=
he Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=
=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>=
.<br>"He ought to find it more profitable to play by the rules" -=
Satoshi Nakamoto</div></div>
</div>
--001a113d4b903769d3052d1e0737--
|
