Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B566273 for ; 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 ; 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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--