there is no internal modification of any file in this commit
files are moved into directories according to established standards in
sourcecode distribution; these directories contain:
src - Files that are used in constructing the executable binaries,
but are not installed.
doc - Files in HTML and text format that document usage, quirks of
the implementation, and contributor checklists.
locale - Files that contain human language translation of strings
used in the program
contrib - Files contributed from distributions or other third party
implementing scripts and auxiliary programs
Information about the best known chain is added to wallet.dat. If this
information does not match the data in blkindex.dat, a rescan is automatically
performed, starting from the the last known block. When upgrading from a wallet
which does not have this information, no rescan is done automatically.
Change some internal data structures to keep track of spentness of each wallet transaction output separately, to support partially-spent transactions:
* an update to the data structures (vfSpent in CWalletTx instead of fSpent)
* a backward-compatible update to the wallet disk format. Old clients reading back an updated wallet will ignore partially spent transactions when creating new ones, and may report a wrong balance, though.
* some helper functions (CWalletTx: IsSpent, MarkSpent, MarkDirty to reset cached values, GetAvailableCredit which only counts unredeemed outputs)
Report coin generation transactions as 'category':'immature' until they have 120 confirmations (when they are reported as 'category':'generate', as before).
If the block they are in is not part of the main chain (you lost a 'block race'), then they are reported as 'category':'orphan' (with 0 confirmations).
SendMoney*() now requires caller to acquire cs_main.
GetAccountAddress() now requires caller to acquire cs_main, cs_mapWallet.
Ordering is intended to match these two callchains[1]:
1. CRITICAL_BLOCK(cs_main)
ProcessMessage(pfrom, strCommand, vMsg)
AddToWalletIfMine()
AddToWallet(wtx)
CRITICAL_BLOCK(cs_mapWallet)
2. CRITICAL_BLOCK(cs_main)
ProcessMessage(pfrom, strCommand, vMsg)
AddToWalletIfMine()
AddToWallet(wtx)
CRITICAL_BLOCK(cs_mapWallet)
walletdb.WriteName(PubKeyToAddress(vchDefaultKey), "")
CRITICAL_BLOCK(cs_mapAddressBook)
Spotted by ArtForz. Additional deadlock fixes by Gavin.
[1] http://www.bitcoin.org/smf/index.php?topic=4904.msg71897#msg71897
Thanks joepie91 for the translation of the new copyright notices into Dutch.
Thanks sipa for the translation of the new copyright notices into French.
Thanks megu for the translation of the new copyright notices into Spanish.
Thanks justmoon/Blitzboom for the translation of the new copyright notices into German.
Thanks Joozero for the translation of the new copyright notices into Italian.
Remaining translations were provided by Google Translate.
Changed algorithm to use continuous exponential function instead of discrete 10-minute window.
Changed -limitfreerelay to be kilobytes-per-minute instead of boolean.
If you copied your wallet and used it on two different machines, the balance reported by getbalance and the sum(listaccounts) could disagree, because you might receive payments for an address that is in your wallet but not your address book. Now all such transactions are credited to the default empty-string account.
Fix two bugs that can happen if you copy your wallet to another machine
and perform transactions on both.
First, ReacceptWalletTransactions would notice if the other wallet spent coins, and
would correctly mark the receiving transaction spent. However, it did not add the spending
transaction to the wallet. Now it does.
Second, account balances could get out of sync with 'getbalance' because coins received
by the other copy of the wallet were not necessarily detected. Now ReacceptWalletTransactions
will scan the entire blockchain for transactions that should be in the wallet if it runs
across a 'spent in the other wallet' transaction.
Finally, there was a small bug in the accounts getbalance code-- generated coins with between
100 and 119 confirmations were not being counted in the balance of account "".
