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
|
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 A10B68B1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Dec 2018 20:37:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f175.google.com (mail-it1-f175.google.com
[209.85.166.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19EE683F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Dec 2018 20:37:31 +0000 (UTC)
Received: by mail-it1-f175.google.com with SMTP id g85so11582596ita.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 03 Dec 2018 12:37:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=sGTw8oinld/1EmHD3Nr20q8OqGNic7grjbLdudyaaQc=;
b=pApRo64Mz5ABXrMBQmr3GhQSk+IPNvYtbZ68r0arR6qMHkFxu93AgRSU+8IdiGm4OI
Hlr/pbhVAeWxOM5OXyWc7WWNg70QjIWvPlvREYLcTcIJ/2l4/fOdDDTbYLvfH8z/JgRn
hvcWPa05JKnfl3DLg5YZtCVcfDTDqRXy++QRyPzyoVpi8MXJ74M0I7yeNdRtl7xj8tID
I8VYuIXDpYyNFHn/9NShQ5BM2cRLaM20gciteZaayiq2AV71knI88n2zp8gtzIulTk3I
tSR1ez0SdVBZpWywqJMa+QI34iUT7aq6evCfKnj2VLiOdxv9RP2zDN9lXGl8rTgdztBk
3iKQ==
X-Gm-Message-State: AA+aEWYcs15QyDuCVEIWfnHuXdZM+s1z3j5vIFH+R4eRl43PCT7yD00h
fDFlUs6tk9ErE9Z5p+w1aM2BxSu1PbR3qin8fFmaKw==
X-Google-Smtp-Source: AFSGD/XrGyCgZcXJgEUU+gO+hLcxahK1Kur1X3VxtxUdAtw4N8L7zn2qHx9ELaHZaxeEx+GA9M6oDoECRIgPh0fDxHo=
X-Received: by 2002:a24:a347:: with SMTP id p68mr9074735ite.141.1543869449937;
Mon, 03 Dec 2018 12:37:29 -0800 (PST)
MIME-Version: 1.0
From: Dave Scotese <dscotese@litmocracy.com>
Date: Mon, 3 Dec 2018 12:37:17 -0800
Message-ID: <CAGLBAhdtXEjhZWavgytQAOuXUaJZc=ZQyvjB2KV-YczAh-H4WQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000024ab2e057c241e61"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Mon, 03 Dec 2018 21:00:05 +0000
Subject: [bitcoin-dev] How much is too much time between difficulty changes?
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, 03 Dec 2018 20:37:31 -0000
--00000000000024ab2e057c241e61
Content-Type: text/plain; charset="UTF-8"
The last difficulty change took about 20% longer than expected. How large
does the time between difficulty changes have to get for us to make
changes? In other words, if, at some point, block confirmation times are
averaging, say, hours or days, will we hardfork to speed things up?
One option is NO. When enough economic interests align to amass the
computing power to get important bitcoin transactions into a block, then
they will work out a way to get that block confirmed. This allows other
cryptocurrencies and technologies like LN to fill in.
There may be a group that will fork the code in order to adjust the
difficulty more rapidly, and bitcoin holders will put a value on
bitcoin-FDA ("Faster-Difficuly-Adjustment"), which is fine with me. We can
learn how to fork peacefully from what we learned when BCH was born, and
what we learned when it split.
I think some insight into how core developers will handle increasing
demands to use faster difficulty adjustments (if they respond at all) will
be helpful, and this is why I'm asking.
Dave Scotese
--00000000000024ab2e057c241e61
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The last difficulty change took about 20% longer than=
expected.=C2=A0 How large does the time between difficulty changes have to=
get for us to make changes?=C2=A0 In other words, if, at some point, block=
confirmation times are averaging, say, hours or days, will we hardfork to =
speed things up?</div><div><br></div><div>One option is NO.=C2=A0 When enou=
gh economic interests align to amass the computing power to get important b=
itcoin transactions into a block, then they will work out a way to get that=
block confirmed.=C2=A0 This allows other cryptocurrencies and technologies=
like LN to fill in.</div><div><br></div><div>There may be a group that wil=
l fork the code in order to adjust the difficulty more rapidly, and bitcoin=
holders will put a value on bitcoin-FDA ("Faster-Difficuly-Adjustment=
"), which is fine with me.=C2=A0 We can learn how to fork peacefully f=
rom what we learned when BCH was born, and what we learned when it split.</=
div><div><br></div><div>I think some insight into how core developers will =
handle increasing demands to use faster difficulty adjustments (if they res=
pond at all) will be helpful, and this is why I'm asking.</div><div><br=
></div><div>Dave Scotese<br></div></div>
--00000000000024ab2e057c241e61--
|
