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
|
Return-Path: <bob_bitcoin@mcelrath.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D050B1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 06:17:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86CEE118
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 06:17:52 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
by mcelrath.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id u296HoT0031540
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Wed, 9 Mar 2016 06:17:50 GMT
Received: (from mcelrath@localhost)
by mcelrath.org (8.14.3/8.14.3/Submit) id u296Ho1p031539;
Wed, 9 Mar 2016 06:17:50 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
bob_bitcoin@mcelrath.org using -f
Date: Wed, 9 Mar 2016 06:17:50 +0000
From: Bob McElrath <bob_bitcoin@mcelrath.org>
To: Daniele Pinna <daniele.pinna@gmail.com>
Message-ID: <20160309061750.GB4388@mcelrath.org>
References: <mailman.6363.1457481624.1673.bitcoin-dev@lists.linuxfoundation.org>
<CAEgR2PFByXpd5C7X2NUJYt+UE3ji6dd6M5LfZGQvg-QQV7fLnw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEgR2PFByXpd5C7X2NUJYt+UE3ji6dd6M5LfZGQvg-QQV7fLnw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
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: Wed, 09 Mar 2016 15:58:14 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 10, Issue 13
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, 09 Mar 2016 06:17:53 -0000
Daniele Pinna via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> This seems unnecessarily complicated ("don't use cannon to kill mosquito" kind
> of thing). If the community were interested in a realtime hashrate rebalancing
> proposal one could simply adjust difficulty at each new block using the current
> method.
That proposal is equivalent to an under-damped oscillator, and would still see
significant oscillation between blocks if miners were switching on and off
hardware.
> If faster relaxation in case of adversity is required, it suspect that it would
> suffice to perform a weighted average of the previous 2016 blocks instead of
> the standard averaging that is currently done. It should be possible to find an
> optimal weighting based on historical interblock timing data. I look into it
> over the next couple of days.
The optimal solution is the one I quote, and is well known, just not in the
bitcoin community.
"faster relaxation time" refers to the time constant of the exponential damping.
if you make it too fast, you create an over-damped oscillator. The system
cannot measure oscillation faster than the block time, so damping on shorter
timescales is useless. The optimal damping is given by the critically damped
oscillator.
Tonight at BitDevsNYC, Mike Wozniak pointed out that SPV wallets must also
calculate retargeting, but this is a terribly simple calculation, and while more
complex from a coding perspective, would not be noticeable in run-time of SPV
wallets.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
|
