- Split linux32/linux64 releases
- Split win32/win64 zips
- Post-processing should no longer be required. The deterministic outputs are
ready for consumption.
- switching release builds to 10.7
- release binary looks like 64bit only
- tested up to 10.10
- gitian builder builds against 10.7. The docs should be consistant.
- remove 32bit text because nowadays it's obvious to support 64bit only on OSX.
Start the RPC server before doing all the (expensive) startup
initialisations like loading the block index. Until the node is ready,
return all calls immediately with a new error signalling "in warmup"
with an appropriate status message (similar to the init message).
This is useful for RPC clients to know that the server is there (e. g.,
they don't have to start it) but not yet available. It is used in
Namecoin and Huntercoin already for some time, and there exists a UI
hooked onto the RPC interface that actively uses this to its advantage.
The homebrew instructions were outdated - berkeley-db4 hasn't worked for months, based on the questions I'm seeing on Google/SO. So I added a section explaining how to install berkeley-db4 using homebrew and move on with your life. Thanks for the rest of the documentation!
Bitcoin core should work with any remotely recent boost version
if a proper build environment is present. Remove a confusing comment
from the build documentation.
Anyone building bitcoind/-qt on windows is welcome to contribute
a new one. The current information in this document is outdated,
or otherwise mostly worthless.
The wallet now uses the mempool fee estimator with a new
command-line option: -txconfirmtarget (default: 1) instead
of using hard-coded fees or priorities.
A new bitcoind that hasn't seen enough transactions to estimate
will fall back to the old hard-coded minimum priority or
transaction fee.
-paytxfee option overrides -txconfirmtarget.
Relaying and mining code isn't changed.
For Qt, the coin control dialog now uses priority estimates to
label transaction priority (instead of hard-coded constants);
unspent outputs were consistently labeled with a much higher
priority than is justified by the free transactions actually
being accepted into blocks.
I did not implement any GUI for setting -txconfirmtarget; I would
suggest getting rid of the "Pay transaction fee" GUI and replace
it with either "target number of confirmations" or maybe
a "faster confirmation <--> lower fee" slider or select box.
Gregory Maxwell