Add an option -detachdb (and entry in OptionDialog), without which no
lsn_reset is called on addr.dat and blkindex.dat. That means these
files cannot be moved to a new environment, but shutdown can be
significantly faster. The wallet file is always lsn_reset'ed.
-detachdb corresponds to the old behaviour, though it is off by
default now to speed up shutdowns.
This commit removes the dependency of serialize.h on PROTOCOL_VERSION,
and makes this parameter required instead of implicit. This is much saner,
as it makes the places where changing a version number can have an
influence obvious.
Conflict:
* cs_main in ProcessMessages() (before calling ProcessMessages)
* cs_vSend in CNode::BeginMessage
versus:
* cs_vSend in ThreadMessageHandler2 (before calling SendMessages)
* cs_main in SendMessages
Even though cs_vSend is a try_lock, if it succeeds simultaneously with
the locking of cs_main in ProcessMessages(), it could cause a deadlock.
Since auto-remove-db-logs was enabled, each time a CTxDB was closed
outside of the initial download window, it causes a checkpoint + log
cleanup. This is overkill, so reduce the sync frequency to once per
minute at most.
Where possible, use boost::filesystem::path instead of std::string or
char* for filenames. This avoids a lot of manual string tinkering, in
favor of path::operator/.
GetDataDir is also reworked significantly, it now only keeps two cached
directory names (the network-specific data dir, and the root data dir),
which are decided through a parameter instead of pre-initialized global
variables.
Finally, remove the "upgrade from 0.1.5" case where a debug.log in the
current directory has to be removed.
For Qt builds, the build.h file is moved to build/build.h. For regular
builds, it is moved to obj/build.h. This allows the Qt build to be done
in a different directory than the source, and without interfering with
other builds.
All client version information is moved to version.cpp, which optionally
(-DHAVE_BUILD_INFO) includes build.h. build.h is automatically generated
on supporting platforms via contrib/genbuild.sh, using git describe.
The git export-subst attribute is used to put the commit id statically
in version.cpp inside generated archives, and this value is used if no
build.h is present.
The gitian descriptors are modified to use git archive instead of a
copy, to create the src/ directory in the output. This way,
src/src/version.cpp will contain the static commit id. To prevent
gitian builds from getting the "-dirty" marker in their git-describe
generated identifiers, no touching of files or running sed on the
makefile is performed anymore. This does not seem to influence
determinism.
Keep a global counter for nOutbound, protected with its own waitable
critical section, and wait when all outbound slots are filled, rather
than polling.
This removes the (on average) 1 second delay between a lost connection
and a new connection attempt, and may speed up shutdowns.
This commit simplifies the locking system: CCriticalSection becomes a
simple typedef for boost::interprocess::interprocess_recursive_mutex,
and CCriticalBlock and CTryCriticalBlock are replaced by a templated
CMutexLock, which wraps boost::interprocess::scoped_lock.
By making the lock type a template parameter, some critical sections
can now be changed to non-recursive locks, which support waiting via
condition variables. These are implemented in CWaitableCriticalSection
and WAITABLE_CRITICAL_BLOCK.
CWaitableCriticalSection is a wrapper for a different Boost mutex,
which supports waiting/notification via condition variables. This
should enable us to remove much of the used polling code. Important
is that this mutex is not recursive, so functions that perform the
locking must not call eachother.
Because boost::interprocess::scoped_lock does not support assigning
and copying, I had to revert to the older CRITICAL_BLOCK macros that
use a nested for loop instead of a simple if.
Do not automatically change the wallet format unless the user takes an
explicit action that implies an upgrade (encrypting, for now), or uses
-walletupgrade.
-walletupgrade optionally takes an integer argument: the client version
up to which upgrading is allowed. Without an argument, it is upgraded
to latest supported version. If an argument to -walletupgrade is
provided at the time the wallet is created, the new wallet will initially
not use features beyond that version.
Third, the current wallet version number is reported in getinfo.
When a 0.6 wallet with compressed pubkeys is created, it writes a
minversion record to prevent older clients from reading it. If the 0.5
loading it sees a key record before seeing the minversion record however,
it will fail with DB_CORRUPT instead of DB_TOO_NEW.
-checkblocks now takes a numeric argument: the number of blocks that must
be verified at the end of the chain. Default is 2500, and 0 means all
blocks.
-checklevel specifies how thorough the verification must be:
0: only check whether the block exists on disk
1: verify block validity (default)
2: verify transaction index validity
3: check transaction hashes
4: check whether spent txouts were spent within the main chain
5: check whether all prevouts are marked spent
6: check whether spent txouts were spent by a valid transaction that consumes them
In cases of very large reorganisations (hundreds of blocks), a situation
may appear where an 'inv' is sent as response to a 'getblocks', but the
last block mentioned in the inv is already known to the receiver node.
However, the supplying node uses a request for this last block as a
trigger to send the rest of the inv blocks. If it never comes, the block
chain download is stuck.
This commit makes the receiver node always request the last inv'ed block,
even if it is already known, to prevent this problem.
Sometimes a new block arrives in a new chain that was already the
best valid one, but wasn't marked that way. This happens for example
when network rules change to recover after a fork.
In this case, it is not necessary to do the entire reorganisation
inside a single db commit. These can become huge, and exceed the
objects/lockers limits in bdb. This patch limits the blocks the
actual reorganisation is applied to, and adds the next blocks
afterwards in separate db transactions.
Introduce the following network rule:
* a block is not valid if it contains a transaction whose hash
already exists in the block chain, unless all that transaction's
outputs were already spent before said block.
Warning: this is effectively a network rule change, with potential
risk for forking the block chain. Leaving this unfixed carries the
same risk however, for attackers that can cause a reorganisation
in part of the network.
Thanks to Russell O'Connor and Ben Reeves.
Before 0.6 addrProxy was a CAddress, but netbase changed it to CService.
Retain compatibility by wrapping/unwrapping with a CAddress when saving
or loading.
This commit retains compatibility with 0.6.0rc1 (which wrote the setting
as a CService) by trying to parse twice.
Doing so would allow an attack on old nodes, which would relay a
standard transaction spending a BIP16 output in an invalid way,
until reaching a new node, which will disconnect their peer.
Reported by makomk on IRC.
Design goals:
* Only keep a limited number of addresses around, so that addr.dat does not grow without bound.
* Keep the address tables in-memory, and occasionally write the table to addr.dat.
* Make sure no (localized) attacker can fill the entire table with his nodes/addresses.
See comments in addrman.h for more detailed information.
When OpenSSL's BN_bn2mpi is passed a buffer of size 4, valgrind
reports reading/writing one byte past it. I am unable to find
evidence of this behaviour in BN_bn2mpi's source code, so it may
be a spurious warning. However, this change is harmless, as only
the bignum with value 0 results in an mpi serialization of size 4.
* do not let vnThreadsRunning[1] go negative
* do not perform locking operations while vnThreadsRunning[1] is decreased
* check vnThreadsRunning[1] at exit
Pieter Wuille