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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to