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
|
Return-Path: <jeanpaulkogelman@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B566273
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jul 2015 04:04:10 +0000 (UTC)
X-Greylist: from 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 8BDE6127
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jul 2015 04:04:09 +0000 (UTC)
Received: from [10.0.1.7] (216-19-182-8.dyn.novuscom.net [216.19.182.8])
by st11p02im-asmtp002.me.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015))
with ESMTPSA id <0NQU01317DYIDM50@st11p02im-asmtp002.me.com> for
bitcoin-dev@lists.linuxfoundation.org;
Thu, 02 Jul 2015 04:03:55 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.14.151,1.0.33,0.0.0000
definitions=2015-07-02_05:2015-06-30, 2015-07-02,
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-1507020068
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
X-Pgp-Agent: GPGMail 2.5
Content-type: multipart/signed;
boundary="Apple-Mail=_CEB68A7F-1668-4AE0-9D81-E86134342A58";
protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Wed, 01 Jul 2015 21:04:19 -0700
Message-id: <F6C7E867-1CCA-4DFB-8A88-361316A76FC3@me.com>
To: bitcoin-dev@lists.linuxfoundation.org
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
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: [bitcoin-dev] Defining a min spec
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: Thu, 02 Jul 2015 04:04:10 -0000
--Apple-Mail=_CEB68A7F-1668-4AE0-9D81-E86134342A58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hi folks,
I=E2=80=99m a game developer. I write time critical code for a living =
and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. =
These budgets are based on what we call a minimum specification (of =
hardware); min spec for short. In most cases the min spec is based on =
entry model machines that are available during launch, and will give the =
user an enjoyable experience when playing our games. Obviously, we can =
turn on a number of bells and whistles for people with faster machines, =
but that=E2=80=99s not the point of this mail.
The point is, can we define a min spec for Bitcoin Core? The number one =
reason for this is: if you know how your changes affect your available =
budgets, then the risk of breaking something due to capacity problems is =
reduced to practically zero.
One way of doing so is to work backwards from what we have right now: =
Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), =
etc. Then there=E2=80=99s Pieter=E2=80=99s analysis of network =
bottlenecks and how it affects orphan rates that could be used to set =
some form of cap on what transfer time + verification time should be to =
keep the orphan rate at an acceptable level.
So taking all of the above (and more) into account, what configuration =
would be the bare minimum to comfortably run Bitcoin Core at maximum =
load and can it be reasonably expected to still be out there in the =
field running Bitcoin Core? Also, can the parameters that were used to =
determine this min spec be codified in some way so that they can later =
be used if Bitcoin Core is optimized (or extended with new =
functionality) and see how it affects the min spec? Basically, with any =
reasonably big change, one of the first questions could be: =E2=80=9CHow =
does this change affect min spec?"
For example, currently OpenSSL is used to verify the signatures in the =
transactions. The new secp256k1 implementation is several times faster =
than (depending on CPU architecture, I=E2=80=99m sure) OpenSSL=E2=80=99s =
implementation. So it would result in faster verification time. This can =
then result in the following things; either network I/O and CPU =
requirements are adjusted downward in the min spec (you can run the new =
Bitcoin Core on a cheaper configuration), or other parameters can be =
adjusted upwards (number of SigOps / transaction, block size?), through =
proper rollout obviously. Since we know how min spec is affected by =
these changes, they should be non-controversial by default. Nobody =
running min spec is going to be affected by it, etc.
Every change that has a positive effect on min spec (do more on the same =
hardware) basically pushes the need to start following any of the curve =
laws (Nielsen, Moore) forward. No need for miners / node operators to =
upgrade.
Once we hit what we call SOL (Speed Of Light, the fastest something can =
go on a specific platform) it=E2=80=99s time to start looking at =
periodically adjusting min spec upwards, or by that time maybe it=E2=80=99=
s possible to use conservative plots of the curve laws as a basis.
Lastly, a benchmark test could be developed that can tell everyone =
running Bitcoin Core how their setup compares to the min spec and how =
long they can expect to run on this setup.
What do you guys think?
jp
--Apple-Mail=_CEB68A7F-1668-4AE0-9D81-E86134342A58
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVlLhEAAoJEG93Vo4Z7tpFBxwQALvp3ZeHR8AB0w6DRdIcZrYD
AH9iB0k2r2oQ0m7a2IY8Vu0aLSyKfs7UgB7xciv39GWoL7u+41eUhgb9tBROpMtZ
NIg7QIpQvaB8v3vhY5Qcle3cy+rMFwIkwAFe25A05NlVnJ+qd0nRAeo+6+hLUgLZ
LiO4MRLwHkJhui2DjuVBbfZsfO7rkiy08ebB2oVsZnZlr789XtA0CndFqm3Q8JaN
zf/80QDeOzwqXSFxOPa3vbnmQIYUf3iJ3KGzSf5vOIlUFeuOO3wELDPmPY/P/CjE
peTVua/L1vOBfIQo8o6qf+7dM9GMimImLGm89DbbOMqxPiJMmyYKlnjndYx1wn7O
NBEoQ8ehdbJ6REYMG1gt6BIsIuVkAEmszDe6EgbgEKSJ8wQvQnZGo1UDBWRmLvNa
2Yp4oO1p7OkKefISfgFMl10Ul7UXGC6QUbq5LRhvsjPng6bKHbbxnXP0NZzz0mPl
1wOHREuNX7JonNUSwdrdjpGXk/CGSUWtqHVsw0X2N6TI2s2SEiyLHEBb2NzkJFUf
NBXLrfosAb1D52YQ5vZTe1J8UiDBLQ3z612PopxxRjk15iE8hZVr1b3ikvQMGNsh
JHs+VWDUm6LCzpLuck8uOZGmXOtV8/J5jvDo1/tTT6iTGlnLH9jd/hmkVBH2fHlg
Jx/A4olmYUQJcZH4Vv/z
=FNTK
-----END PGP SIGNATURE-----
--Apple-Mail=_CEB68A7F-1668-4AE0-9D81-E86134342A58--
|
