From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B33C4B88 for ; Thu, 2 Jul 2015 07:25:23 +0000 (UTC) X-Greylist: delayed 00:06:52 by SQLgrey-1.7.6 Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7925139 for ; Thu, 2 Jul 2015 07:25:22 +0000 (UTC) Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de [134.60.77.114]) (authenticated bits=0) by mail.uni-ulm.de (8.14.9/8.14.7) with ESMTP id t627IJQF021951 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 2 Jul 2015 09:18:26 +0200 (CEST) Date: Thu, 2 Jul 2015 09:18:14 +0200 From: Henning Kopp To: Jean-Paul Kogelman Message-ID: <20150702071814.GA1904@banane.informatik.uni-ulm.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-DCC-debian-Metrics: poseidon 1169; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: by amavisd-new X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [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 07:25:23 -0000 Hi Jean-Paul, that's a very interesting point of view and I have never thought about it this way, since I have a totally different background. How would you go on about defining a min spec? Is this done by testing the software on different hardware configurations or are you looking at the requirements a priori? Best regards Henning On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote: > Hi folks, > > I’m 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’s 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’s Pieter’s 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: “How 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’m sure) OpenSSL’s 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’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Henning Kopp Institute of Distributed Systems Ulm University, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp