From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
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\))
Subject: [bitcoin-dev] Defining a min spec
Precedence: list


--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--