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
|
Return-Path: <jakob.ronnback@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95235892
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 14:49:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com
[17.172.220.114])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B080E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 14:49:06 +0000 (UTC)
Received: from [10.0.1.60] (h-29-43.a159.priv.bahnhof.se [79.136.29.43])
by st11p02im-asmtp002.me.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015))
with ESMTPSA id <0NT200P4HUHC9I30@st11p02im-asmtp002.me.com> for
bitcoin-dev@lists.linuxfoundation.org;
Fri, 14 Aug 2015 14:48:51 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.14.151,1.0.33,0.0.0000
definitions=2015-08-14_06:2015-08-13, 2015-08-14,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1412110000
definitions=main-1508140212
From: =?utf-8?Q?Jakob_R=C3=B6nnb=C3=A4ck?= <jakob.ronnback@me.com>
Content-type: multipart/alternative;
boundary="Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F"
Message-id: <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com>
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Date: Fri, 14 Aug 2015 16:48:48 +0200
References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
<CAJS_LCWRagQ40c28SGetxeHxnk8FqY3y_X0OxfqaiLbd25dSGg@mail.gmail.com>
<A6B32C22-4006-434E-9B89-D7C99B5743A8@me.com>
To: bitcoin-dev@lists.linuxfoundation.org
In-reply-to: <A6B32C22-4006-434E-9B89-D7C99B5743A8@me.com>
X-Mailer: Apple Mail (2.2102)
X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,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
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative
blocksize
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: Fri, 14 Aug 2015 14:49:06 -0000
--Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> 14 aug 2015 kl. 16:20 skrev Anthony Towns <aj@erisian.com.au =
<mailto:aj@erisian.com.au>>:
>=20
> On 14 August 2015 at 11:59, Jakob R=C3=B6nnb=C3=A4ck =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> What if one were to adjust the difficulty (for individual blocks) =
depending on the relative size to the average block size of the previous =
difficulty period? (I apologize if i=E2=80=99m not using the correct =
terms, I=E2=80=99m not a real programmer, and I=E2=80=99ve only recently =
started to subscribe to the mailing list)
>=20
> =E2=80=8BThat would mean that as usage grew, blocksize could increase, =
but confirmation times would also increase (though presumably less than =
linearly). That seems like a loss?
>=20
Would that really be the case though? If it takes 5% to find a block, =
but it contains 5% more transactions would that not mean it=E2=80=99s =
the same? That would argue against the change if not for the fact that =
the blocks will be bigger for the next difficulty period.
> If you also let the increase in confirmation time (due to miners =
finding harder blocks rather than a reduction in hashpower) then get =
reflected back as decreased difficulty, it'd probably be simpler to just =
dynamically adjust the max blocksize wouldn't it?
>=20
I guess that could make the difficulty fluctuate a bit depending on the =
amount of transactions and the fees being paid. Would it really matter =
in the long run though? Since it=E2=80=99s the same amount of miners, =
doesn=E2=80=99t that just mean it=E2=80=99s just the number that is =
lower, not the actual investment needed to mine the blocks? Not sure if =
this would open up some forms of attacks on the system for someone =
willing to lose money though=E2=80=A6
Very good feedback though, thanks a lot :)
/jakob=
--Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">14 aug 2015 kl. 16:20 skrev =
Anthony Towns <<a href=3D"mailto:aj@erisian.com.au" =
class=3D"">aj@erisian.com.au</a>>:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_default" style=3D"font-family: =
monospace;"><span class=3D"" style=3D"font-family: arial, =
sans-serif;">On 14 August 2015 at 11:59, Jakob =
R=C3=B6nnb=C3=A4ck </span><span dir=3D"ltr" class=3D"" =
style=3D"font-family: arial, sans-serif;"><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>></span><span =
class=3D"" style=3D"font-family: arial, =
sans-serif;"> wrote:</span><br class=3D""></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">What if one were to adjust =
the difficulty (for individual blocks) depending on the relative size to =
the average block size of the previous difficulty period? (I apologize =
if i=E2=80=99m not using the correct terms, I=E2=80=99m not a real =
programmer, and I=E2=80=99ve only recently started to subscribe to the =
mailing list)<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div><div class=3D""><div class=3D"gmail_default" =
style=3D"font-family: monospace;">=E2=80=8BThat would mean that as usage =
grew, blocksize could increase, but confirmation times would also =
increase (though presumably less than linearly). That seems like a =
loss?</div><div class=3D"gmail_default" style=3D"font-family: =
monospace;"><br =
class=3D""></div></div></div></div></div></div></blockquote><div =
class=3D""><br class=3D""></div>Would that really be the case though? If =
it takes 5% to find a block, but it contains 5% more transactions would =
that not mean it=E2=80=99s the same? That would argue against the change =
if not for the fact that the blocks will be bigger for the next =
difficulty period.</div><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><div =
class=3D"gmail_default" style=3D"font-family: monospace;">If you also =
let the increase in confirmation time (due to miners finding harder =
blocks rather than a reduction in hashpower) then get reflected back as =
decreased difficulty, it'd probably be simpler to just dynamically =
adjust the max blocksize wouldn't it?</div><div class=3D"gmail_default" =
style=3D"font-family: monospace;"><br =
class=3D""></div></div></div></div></div></blockquote><br =
class=3D""></div><div class=3D"">I guess that could make the difficulty =
fluctuate a bit depending on the amount of transactions and the fees =
being paid. Would it really matter in the long run though? Since it=E2=80=99=
s the same amount of miners, doesn=E2=80=99t that just mean it=E2=80=99s =
just the number that is lower, not the actual investment needed to mine =
the blocks? Not sure if this would open up some forms of attacks on the =
system for someone willing to lose money though=E2=80=A6</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">Very good feedback though, thanks a lot :)</div><div =
class=3D""><br class=3D""></div><div =
class=3D"">/jakob</div></div></body></html>=
--Apple-Mail=_1CA12C5C-50FB-4153-B72A-23AC0006C25F--
|
