summaryrefslogtreecommitdiff
path: root/ef/4516cc0edc73d124b9282b81034141b93a9fca
blob: 14f8df2c11936b4890708fb48eaf456d5ad4dd12 (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
Return-Path: <zawy@yahoo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 423BD9BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  9 Oct 2017 23:07:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from sonic316-9.consmr.mail.gq1.yahoo.com
	(sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.33])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9FFCA196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  9 Oct 2017 23:07:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1507590455; bh=8bPlkIEv8i90uXh3HbI+EiXk5CRKoS23v/YTsKSGtek=;
	h=Date:From:Reply-To:To:Subject:References:From:Subject;
	b=MYxyiuZc2XxqcHOt73UmWb7LpBBpB+BhIxIMiWZ+LBY8nOTEBAK65OGJnmXHmZJmZdInUY6+Lk94R7303F9IVOJbM8G48eldD2O9Dt+fsXBRLVi4BcGyALSVQViOvkUs0Tjl0wGg9BHZzusHPMZ5CUyQ+XvXVBFOlEEG/7tfpdqY7JajEbBpT8x3Zm9MTLSpJHKMF8F/zebC5n+gkCuVMvpbRS7bgBwdwQlup3eMKM043TFvnIi7u1BZlqtlGOisz6tp1tTuUEyGnpScDyA8S4jM7YL+iDVePiQ5fPx7lkuYuuCA+CTiCp/Lbl4s8fsuKhyQr0OkozekSCcl/cY73w==
X-YMail-OSG: s__W7vAVM1kKd5jQ2K3mSTNUHu6LCTzKLXeBwr0FPrHzsY4chJJSoaXAZys1ZVg
	p.zlLKFdpBFJYgYjdrRtWExFCEWxICDpluly.U2f.y8oIolFmPN4sqlbGFyTNk4oq943f3euLB2V
	5adFVus.hlCXeN36_Zp74I4S.swPAEnieN_GRGuyYrmAA5jsZx98b5I7l2_fG..azD5p4Iqf_lqH
	LV6HFCSe3OV3nQHm19mmEAB75.zxerIJIQDpnwTW4vB4gTXwnH7nFJETjR2lJNevzr8b6zvCZkOF
	fKL7UQfUY_OKeUTFDUK5jag9MzLmrDQH7Y8G6t5wBlPbEHVfUbn.cw32MTbNXhmOQ2Di7riEqhw.
	IPDxf7pfiDlL3IBxHuisSkn02Mzzb5RvzgymsaJliy9uO4YrFS5Qv6XpZpD2w8gsgf5R20Rt2dlG
	ad21.Na1bDxJ8NfPJ4z.VpPssdmtOs2qsg1IB24ukEq68xOxWOQPuK6zMqWr3J6l6NaNhV.rHmRg
	gaujor0Gi9hNVIAYaPhNW.MAQF59oyUA2wAbBzHIXo7L0eN33Q6ndBbMw3Q--
Received: from sonic.gate.mail.ne1.yahoo.com by
	sonic316.consmr.mail.gq1.yahoo.com with HTTP;
	Mon, 9 Oct 2017 23:07:35 +0000
Date: Mon, 9 Oct 2017 22:57:32 +0000 (UTC)
From: Scott Roberts <zawy@yahoo.com>
Reply-To: Scott Roberts <zawy@yahoo.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <1213518291.4328204.1507589852818@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.10668 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64;
	x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100
	Safari/537.36
X-Spam-Status: No, score=1.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FORGED_MUA_MOZILLA,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,
	RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 09 Oct 2017 23:16:41 +0000
Subject: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork?
 (reformatted text)
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: Mon, 09 Oct 2017 23:07:36 -0000

Sorry, my previous email did not have the plain text I intended.

Background: 

The bitcoin difficulty algorithm does not seem to be a good one. If there 
is a fork due to miners seeking maximum profit without due regard to 
security, users, and nodes, the "better" coin could end up being the 
minority chain. If 90% of hashrate is really going to at least initially go 
towards using SegWit2x, BTC would face 10x delays in confirmations 
until the next difficulty adjustment, negatively affecting its price relative 
to BTC1, causing further delays from even more miner abandonment 
(until the next adjustment). The 10% miners remaining on BTC do not 
inevitably lose by staying to endure 10x delays because they have 10x 
less competition, and the same situation applies to BTC1 miners. If the 
prices are the same and stable, all seems well for everyone, other things 
aside. But if the BTC price does not fall to reflect the decreased hashrate, 
he situation seems to be a big problem for both coins: BTC1 miners will 
jump back to BTC when the difficulty adjustment occurs, initiating a 
potentially never-ending oscillation between the two coins, potentially 
worse than what BCH is experiencing.  They will not issue coins too fast 
like BCH because that is a side effect of the asymmetry in BCH's rise and 
fall algorithm. 

Solution: 

Hard fork to implement a new difficulty algorithm that uses a simple rolling 
average with a much smaller window.  Many small coins have done this as 
a way to stop big miners from coming on and then suddenly leaving, leaving 
constant miners stuck with a high difficulty for the rest of a (long) averaging 
window.  Even better, adjust the reward based on recent solvetimes to 
motivate more mining (or less) if the solvetimes are too slow (or too fast). 
This will keep keep coin issuance rate perfectly on schedule with real time. 

I recommend the following for Bitcoin, as fast, simple, and better than any 
other difficulty algorithm I'm aware of.  This is the result of a lot of work the 
past year. 

=== Begin difficulty algorithm === 
# Zawy v6 difficulty algorithm (modified for bitcoin) 
# Unmodified Zawy v6 for alt coins: 
# http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html 
# All my failed attempts at something better: 
# https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a 
# 
# Keep negative solvetimes to correct bad timestamps. 
# Do not be tempted to use: 
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; 
# ST= Solvetime, TS = timestamp 

# set constants until next hard fork: 

T=600; # coin's TargetSolvetime 
N=30; # Averaging window. Smoother than N=15, faster response than N=60. 
X=5; 
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation 
adjust = 1/(1+0.67/N);  # keeps avg solvetime on track 

# begin difficulty algorithm 

avg_ST=0; avg_D=0; 
for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks 
avg_ST += (TS[i] - TS[i-1]) / N; 
avg_D += D[i]/N; 
} 
avg_ST = T*limit if avg_ST > T*limit; 
avg_ST = T/limit if avg_ST < T/limit; 

next_D = avg_D * T / avg_ST * adjust; 

# Tim Olsen suggested changing reward to protect against hash attacks. 
# Karbowanek coin suggested something similar. 
# I could not find anything better than the simplest idea below. 
# It was a great surprise that coin issuance rate came out perfect. 
# BaseReward = coins per block 

next_reward = BaseReward * avg_ST / T; 

======= end algo ==== 

Due to the limit and keeping negative solvetimes in a true average, 
timestamp errors resulting in negative solvetimes are corrected in the next 
block. Otherwise, one would need to do like Zcash and cause a 5-block 
delay in the response by resorting to the median of past 11 blocks (MPT) 
as the most recent timestamp, offsetting the timestamps from their 
corresponding difficulties by 5 blocks. (it does not cause an averaging 
problem, but it does cause a 5-block delay in the response.)