Age | Commit message (Collapse) | Author |
|
|
|
Introduce explicit -walletupgrade option
|
|
Remove unused functions from util.h/util.cpp (EOM)
|
|
This speeds up initial connections with an old/large addr.dat a lot.
|
|
|
|
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.
|
|
|
|
Check minversion before loading the rest of the wallet
|
|
|
|
Speed up block downloading
|
|
|
|
replace call to PrintConsole with call to error()
|
|
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
|
|
|
|
As these are equivalent functions, this cleans up the source a bit.
Also remove PrintConsole() as this was the only use.
|
|
When disconnecting a node, the receive buffer should be cleared
|
|
Prevent stuck block download in large reorganisations
|
|
The generic UNIX Makefile builds with lots of warnings
|
|
|
|
|
|
language updates for source file bitcoin_en.ts + remove cs_CZ (issue #958)
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
german translation update
|
|
|
|
|
|
Make send coins dialog honor the configured unit type even on the first attempt.
|
|
Wallet loading diagnostic prints to debug.log
|
|
attempt.
|
|
not process any already received messages.
The primary reason to do this is if a node spams hundreds of messages
and we ban them, we don't want to continue processing the rest of it.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2^31 milliseconds is only about 25 days. Also clamps Sleep() to 10 years,
because it currently sleeps for 0 seconds when the sleep time would cross
2^31 seconds since the epoch. Hopefully boost will be fixed by 2028.
|
|
|
|
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.
|
|
|
|
|