summaryrefslogtreecommitdiff
path: root/d5/7ddef4cc7f80b72a66ed58d75818eae856df62
blob: f9a633bd1ac694eddcf0046173581a471761d586 (plain)
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
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9AE4FDAF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  2 Mar 2016 15:54:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
	[209.85.213.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35765193
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  2 Mar 2016 15:54:16 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id k196so206872299vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 02 Mar 2016 07:54:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; 
	bh=P+BztshTPSDStDlDck6cQgM7ygqCQ7ZqfC/9iisQmLs=;
	b=aIBrdqrs2P5eaeyTlSfJDT+duKaiA7c2huy2NrnmxFy+kiNKMM4vUGm8JHwynzPEra
	Cp+fhvUcb+YwIueVNNLwunQQ2+Xhe0ObzmzshKuEobb4X33yaiZdG+jhcYt7yGwvBrNA
	N2ROZcj7LRCwXCfx7YPU/LSVTBXAPKl+1sFROrYig8kqOpXORtEHE7nSlOra2SnPvKRo
	qUmNktMnLdk1YtYsVbebQ8PUdXhZLI8o7lisy9guc9AHt4tZfKkR9ZSjDgV10v0kz9lc
	dXynMoUvn9dCXkkK6ZpV7+hQjmFryTO1wh3vO/0qNMa8m5tShNcE4qJBooSpMNZJRNnK
	YeYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:cc;
	bh=P+BztshTPSDStDlDck6cQgM7ygqCQ7ZqfC/9iisQmLs=;
	b=i9vDZoZ/XmbARTEYe/ZaFwxlsay//+v0L+aZ05DG2aHiIJ7PJRIqv0gZ1Q1l3AAAde
	ixQ1rYDU9/DK5UL0dLfLYjgVrhAx0awTH7XuzTbjrbWk6uyXQuWudipC+nSS+bEHnE6c
	dSo4tl6PnfdkoWdm0+EVnYaAZ7azR7neKW9VhxmgJUKeU0fdmsNuAXgY95H8WxEitkCX
	NBE5T/rrkkFo3aqpg2gua46MFPEHARp2AFZVbSEiFb+2wd2ssCQ+F9g6anvRqyL4fLzZ
	VzPA+Ok9UkG9V/s6IGo0q5H2KrW82XxCVPawKANIoLdV1R40TtPb4vEX1So2KZbmDgLr
	Rtaw==
X-Gm-Message-State: AD7BkJJ6Rxnq6PArCJLlb31kdCL4Rjk39qkSZuHT1RQMNvdOFJ+HXItp0san4gyeKqqJv7Tfsxaq+bGwNvpjXg==
MIME-Version: 1.0
X-Received: by 10.31.10.199 with SMTP id 190mr21342243vkk.51.1456934055435;
	Wed, 02 Mar 2016 07:54:15 -0800 (PST)
Received: by 10.159.37.137 with HTTP; Wed, 2 Mar 2016 07:54:15 -0800 (PST)
In-Reply-To: <CAE-z3OUR8So2EM_EBeEerW-UPs0KY+whVB=jjFAHkW3xZPF2Hw@mail.gmail.com>
References: <201603021456.15820.luke@dashjr.org>
	<B9C659DC-1954-45C2-B3E6-552A17CDD655@Janik.cz>
	<201603021514.36769.luke@dashjr.org>
	<CAE-z3OUR8So2EM_EBeEerW-UPs0KY+whVB=jjFAHkW3xZPF2Hw@mail.gmail.com>
Date: Wed, 2 Mar 2016 15:54:15 +0000
Message-ID: <CAE-z3OXjt4E9a2iMCd51=9F6v0iG0NE5JSkOvKqkeQzWewG7pg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11440176d5e4cb052d12e46e
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 02 Mar 2016 15:59:39 +0000
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: Wed, 02 Mar 2016 15:54:16 -0000

--001a11440176d5e4cb052d12e46e
Content-Type: text/plain; charset=UTF-8

If a hard-fork is being considered, the easiest is to just step the
difficulty down by a factor of 2 when the adjustment happens.

This means that miners still get paid the same minting fee per hash as
before.  There isn't that much risk.  If the hashing power stays constant,
then there will be 5 minute blocks for a while until everything readjusts.

Nearly the same can be accomplished by a soft fork.

Proposal:

If 900 of the last 1000 blocks are block version X or above, then the
smooth change rule applies.

The adjustment is as follows

big_number get_new_target(int height, big_number old_target) {
    if (height < 405000)
        return old_target;
    else if (height < 420000)
        return (old_target * 15000) / (height - 390000);
    else
        return old_target;
}

What this does is ramp up the difficulty slowly from 405,000 to 420,000.
It ends up with a target that is 50% of the value stored in target bits.
These blocks are valid since they have twice as much POW as normally
required.

For block 420000, the difficulty drops by 2 and the reward drops by 2 at
the same time.  This means that miners still get paid the same BTC per
hash.  It would mean 5 minute blocks until the next adjustment though.

If 90% of the network are mining the artificially hard blocks, then a  10%
fork still loses.  The 90% has an effective hash rate of 45% vs the 10%.

It is unlikely that miners would accept the fork, since they lose minting
fees.  It effectively brings the subsidy reduction forward in time.

--001a11440176d5e4cb052d12e46e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>If a hard-fork is being=
 considered, the easiest is to just step the difficulty down by a factor of=
 2 when the adjustment happens.<br><br></div><div>This means that miners st=
ill get paid the same minting fee per hash as before.=C2=A0 There isn&#39;t=
 that much risk.=C2=A0 If the hashing power stays constant, then there will=
 be 5 minute blocks for a while until everything readjusts.<br></div><div><=
br></div><div></div><div>Nearly the same can be accomplished by a soft fork=
.<br></div><div><br></div><div>Proposal: <br></div><br>If 900 of the last 1=
000 blocks are block version X or above, then the smooth change rule applie=
s.<br><br></div>The adjustment is as follows<br><br></div>big_number get_ne=
w_target(int height, big_number old_target) {<br></div>=C2=A0=C2=A0=C2=A0 i=
f (height &lt; 405000)<br></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
return old_target;<br></div>=C2=A0=C2=A0=C2=A0 else if (height &lt; 420000)=
<br></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return (old_target * 1=
5000) / (height - 390000);<br><div>=C2=A0=C2=A0=C2=A0 else<br></div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return old_target;<br>}<br><br><=
/div><div>What this does is ramp up the difficulty slowly from 405,000 to 4=
20,000.=C2=A0 It ends up with a target that is 50% of the value stored in t=
arget bits.=C2=A0 These blocks are valid since they have twice as much POW =
as normally required.<br><br></div><div>For
 block 420000, the difficulty drops by 2 and the reward drops by 2 at=20
the same time.=C2=A0 This means that miners still get paid the same BTC per=
=20
hash.=C2=A0 It would mean 5 minute blocks until the next adjustment though.=
<br><br></div><div>If
 90% of the network are mining the artificially hard blocks, then a=C2=A0
10% fork still loses.=C2=A0 The 90% has an effective hash rate of 45% vs th=
e 10%.<br><br></div><div>It is unlikely that miners would accept the fork, =
since they lose minting fees.=C2=A0 It effectively brings the subsidy reduc=
tion forward in time.<br></div></div>

--001a11440176d5e4cb052d12e46e--