Download a third party pre-compiled binary at your own risk.

Validation.h
static const int MAX_SCRIPTCHECK_THREADS = 32; /16/

Useful for those who have PC's with greater than 32 physical cores, otherwise increased context switching will make it slower.

Several people have suggested increasing outbound connections over the years, the answer has always been "don't do this it's bad!" or words to that effect.

This is one from recently https://github.com/bitcoin/bitcoin/issues/9217

Many others if you google around.

There is no such thing as "official" source for bitcoin.

There is a source that is called "Bitcoin Core" by it's developers, and that source is probably the most popular source at the moment, but there isn't anything "official" about it, and it may not always be the most popular.


What is important when it comes to running bitcoin software is to use OPEN source (source code that is available for EVERYONE to read) which is well reviewed (not brand new source that nobody has every seen before or which very few people have looked over).  And to be certain that any binary you download was actually built from that exact source and not some variation.

Sorry i was not able to upload 3.2Gb of Ubuntu VM Vare image, but now - it is done - everybody can check everything or build/compile his own core for Windows / Linux / Mac.
To get latest Bitcoin Core sources use command:
git clone https://github.com/bitcoin/bitcoin.git

AngryDwarf
Did you see CPU-load more than 70% even if you launch with -par=16 on i7 quadcore-cpu (i did not on i7-2630QM)

sgbett
I may agree a little with you but on your link there were no tech explanation why MAX_OUTBOUND_CONNECTIONS >8 is very bad.
To the end user, especially if he launches the wallet with interval a week/month - it is very good, because he may sync very fast, also it is good because his transaction will be BROADCASTED via a lot of nodes, sometimes it helps to pay less fee to be earlier confirmed.

Thanks for critics.

I have been reading and trying to understand the lines clearly but I was hesitant to download the file. There are many thoughts that comes into my mind since we are using a third party client. But I will check and read reviews on this one so I could get the advantages and disadvantages of using this kind of system. I cannot make a god comment on this since I havent tried it yet, I am hoping for somebody who tried this system and has a good experience.

Go ahead and do what you like, but I don't think it will do what you think it will... I'd urge others to read this other post (by Pieter Wuille) before making up their own mind about whether its good/necessary:

http://bitcoin.stackexchange.com/questions/8109/how-does-one-attain-1-000-connections-like-blockchain-info/8140#8140

This is not useful when you have more than 16 cores: it will be considerably slower, even when you do have many cores. The numbers were set based on actual measurement on 48 core systems. Overheads dominate by the point of 16 script check threads.

Similarly, increasing outbound connections just wastes resources, severely _hurts_ your latency, and will end up getting you banned by many people (same thing for the addnode maximum).  (Several people correlate hosts that are mass connecting and add them to shared ban-lists -- once your address is on these lists it won't come off for a long time).

It will also not improve your sync speed on practically any system-- sync is verification/database bound and when it isn't, it's usually reorder buffer bound.

The outbound connection increase is especially bad for miners because it increases your connection service loop time, and keeps your block in the linear regime longer where  it's just your node replicating the block rather than an exponentially growing cone.  An optimized mining setup has mining nodes with a minimal number of connections connecting to multiple border nodes and relay networks (e.g. two local border nodes, one remote border node, two reliable external nodes, and one relay network). At least one of the border nodes should  be outbound only, and at least one should accept inbound (usually best to do with remote nodes, in case it attracts dos attacks).


Most of the other settings changed can just be changed with the config file and command-line, anything with "DEFAULT" in the name.


The download window changes will likely cause database corruption if you use them with pruning. The checkblocks/checklevel changes will do effectively nothing (also controllable from the commandline).  The MAX_BLOCKS_TO_ANNOUNCE will just waste your bandwidth in the event of a huge reorg.

The timeout interval change will make you easier to DOS attack, causing you to wait longer on messages that will never be answered.

This is absolutely untrue. What you broadcast to has nothing to do with what fees you pay.  


I hope you have at least 32 GB of ram, because that is the peak memory usage these (commandline accessible) options imply on top of the nearly 2.5GB of other usage implied by  other settings.

Which permits optimizations which may produce incorrect results... mostly which shouldn't matter for Bitcoin Core, but O3 should also be just as fast and would only suffer from compiler bugs, and not directly unsafe optimizations.

Virtually all these settings which can be safely tinkered without much danger of screwing things up and without musch understanding are command-line options.

Changing things further is great-- but you should probably take some more time to understand what you're changing, especially before inviting others to use your changes!

Work on making the rescan faster would be very welcome. The largest likely improvement there would be bypassing hash validation when reading blocks from disk.

gmaxwell
Great thanx and RESPECT!!!

-O2 is really safe and some dependencies has base setiings like -O3 and so on, actually i did not see incorrect results, but when to complile with mingw 5.3.0+ there are bugs with linking and etc. there are no posibility to build. Probably it is better when one process takes a little less CPU time to get more for another one.
I think it is worsting of time because of linking problems, but i like that "fine" tuning and have idea to compile deps with latest compiler like 6.3.0 and Core with 4.8.2 or in another sequence - Perfectionism is our all  

You are very right that there are a lot of possibilities to get ban-score, but i argue with you that my version will sync faster - will try to bench both Official and my compilation on weekend and measure time.

Fee theme:
I did not get to the source [Since this began here, then I feel that I will study the mechanisms very deeply, or maybe not, maybe it's just a waste of time and the satisfaction of ego] but as understand if pool get transaction:
it will make command like a prioritize_transaction depending on fee, so if all pools get that transaction to their mempool in one time-frame window(i assume that other transactions will come in next frame, because of less broadcasting) then there are possibility that pool which first mine the block will have your transaction little above others in the list. Another pool probably will get more transactions with bigger fees at the same window and the same transaction has less priority and if first pool does not mined the second will mined it on next block.. [sorry for English, it is really hard to suggest/explain].


AngryDwarf
It would be great if we will see your optimization of parallel processing.

It is very important to use bitcoin as the source code, we are not allowed to use source code with harmful changes. I think we should use the most popular source code released by the publishers, which is safer and more convenient. You need to have a deeper look at the source code for best insight, besides, you also have parallel processing and data synchronization to enhance the core. Most of the changes occur in the files and the command line, so if the change will cause unintended consequences.