Age | Commit message (Collapse) | Author |
|
Conflicts:
makefile.unix
|
|
Accept non-standard transactions on testnet.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
When starting the client, ReacceptWalletTransaction didn't skip spent transactions in its loop, and processed all old spent transactions again.
|
|
|
|
|
|
Update to SelectCoins and CreateTransaction to select source transaction outputs separately instead of per whole transaction.
|
|
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
|
|
|
|
build time(statically linked).
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.
|
|
|
|
and CreateBlock
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 "".
|
|
|
|
listtransactions '*'
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@203 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@200 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@199 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
can understand.
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@197 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
jgarzik's initial download speedup
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@195 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@194 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
getbalance <account>
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@193 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@189 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@186 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
spam
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@185 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@184 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@177 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
BitcoinMiner prioritise transactions by how old their dependencies are
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@176 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@175 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|
|
addr system changes,
make sure no gen before block 74000
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@173 1a98c847-1fd6-4fd8-948a-caf3550aa51b
|