@ -36,7 +36,7 @@ every time you wish to send Bitcoins. If you lose this passphrase,
@@ -36,7 +36,7 @@ every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
password in a secure location and do not forget it.
passphrase in a secure location and do not forget it.
Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
@ -57,7 +57,7 @@ If everything goes fine, delete the backup and enjoy your encrypted
@@ -57,7 +57,7 @@ If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.
Keep in mind that you are always responsible for you own security.
Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
@ -67,6 +67,50 @@ entering your wallet passphrase in the Bitcoin client and using the
@@ -67,6 +67,50 @@ entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.
Technical details of wallet encryption
--------------------------------------
Wallet encryption uses AES-256-CBC to encrypt only the private keys
that are held in a wallet. The keys are encrypted with a master key
which is entirely random. This master key is then encrypted with
AES-256-CBC with a key derived from the passphrase using SHA512 and
OpenSSL's EVP_BytesToKey and a dynamic number of rounds determined by
the speed of the machine which does the initial encryption (and is
updated based on the speed of a computer which does a subsequent
passphrase change). Although the underlying code supports multiple
encrypted copies of the same master key (and thus multiple passphrases)
the client does not yet have a method to add additional passphrases.
At runtime, the client loads the wallet as it normally would, however
the keystore stores the keys in encrypted form. When the passphrase
is required (to top up keypool or send coins) it will either be queried
by a GUI prompt, or must first be entered with the walletpassphrase
RPC command. This will change the wallet to "unlocked" state where the
unencrypted master key is stored in memory (in the case of GUI, only for
long enough to complete the requested operation, in RPC, for as long as
is specified by the second parameter to walletpassphrase). The wallet is
then locked (or can be manually locked using the walletlock RPC command)
and the unencrypted master key is removed from memory.
Implementation details of wallet encryption
-------------------------------------------
When the wallet is locked, calls to sendtoaddress, sendfrom, sendmany,
and keypoolrefill will return Error -13: "Error: Please enter the wallet
passphrase with walletpassphrase first."
When the wallet is unlocked, calls to walletpassphrase will fail.
When a wallet is encrypted, the passphrase is required to top up the
keypool, thus, if the passphrase is rarely entered, it is possible that
keypool might run out. In this case, the default key will be used as the
target for payouts for mining, and calls to getnewaddress and getaccount
address will return an error. In order to prevent such cases, the keypool
is automatically refilled when walletpassphrase is called with a correct
passphrase and when topupkeypool is called (while the wallet is unlocked).
Note that the keypool continues to be topped up on various occasions when
a new key from pool is used and the wallet is unlocked (or unencrypted).
@ -57,7 +57,7 @@ classes that do the rote work of constructing all the UI elements.
@@ -57,7 +57,7 @@ classes that do the rote work of constructing all the UI elements.
wxWidgets
---------
DOS shell:
cd \wxWidgets-2.9.1-mgw\build\msw
cd \wxWidgets-2.9.2-mgw\build\msw
mingw32-make -f makefile.gcc
OpenSSL
@ -73,30 +73,26 @@ make
@@ -73,30 +73,26 @@ make
Berkeley DB
-----------
MSYS shell:
cd /c/db-4.7.25.NC-mgw/build_unix
cd /c/db-4.8.30.NC-mgw/build_unix
sh ../dist/configure --enable-mingw --enable-cxx
make
Boost
-----
DOS prompt:
downloaded boost jam 3.1.18
cd \boost-1.43.0-mgw
cd \boost-1.47.0-mgw
bjam toolset=gcc --build-type=complete stage
Note:
building with boost 1.45.0 failed because of boost ticket 4614, 4258
builds fine with boost 1.43.0
MiniUPnPc
---------
Building miniupnpc failed on Windows Server 2003, thus it is expected that a binary copy will be used.
See http://miniupnp.tuxfamily.org/forum/viewtopic.php?t=642
UPnP support is optional, make with USE_UPNP= to disable it.
Get upnpc-exe-win32-20110215.zip and unzip it to \upnpc-exe-win32-20110215
Get miniupnpc-1.5.20110215.tar.gz and copy *.h to \upnpc-exe-win32-20110215\miniupnpc
@ -135,18 +135,18 @@ The process for miniupnpc (optional) is similar to that of OpenSSL.
@@ -135,18 +135,18 @@ The process for miniupnpc (optional) is similar to that of OpenSSL.
Download from http://miniupnp.tuxfamily.org/files/.
@ -39,3 +39,47 @@ v vector or similar list objects
@@ -39,3 +39,47 @@ v vector or similar list objects
map map or multimap
set set or multiset
bn CBigNum
-------------------------
Locking/mutex usage notes
The code is multi-threaded, and uses mutexes and the CRITICAL_BLOCK/TRY_CRITICAL_BLOCK macros to protect data structures.
Deadlocks due to inconsistent lock ordering (thread 1 locks cs_main and then cs_wallet, while thread 2 locks them in the opposite order: result, deadlock as each waits for the other to release its lock) are a problem. Compile with -DDEBUG_LOCKORDER to get lock order inconsistencies reported in the debug.log file.
Re-architecting the core code so there are better-defined interfaces between the various components is a goal, with any necessary locking done by the components (e.g. see the self-contained CKeyStore class and its cs_KeyStore lock for example).
-------
Threads
StartNode : Starts other threads.
ThreadGetMyExternalIP : Determines outside-the-firewall IP address, sends addr message to connected peers when it determines it.
ThreadIRCSeed : Joins IRC bootstrapping channel, watching for new peers and advertising this node's IP address.
ThreadSocketHandler : Sends/Receives data from peers on port 8333.
ThreadMessageHandler : Higher-level message handling (sending and receiving).
ThreadOpenConnections : Initiates new connections to peers.
ThreadTopUpKeyPool : replenishes the keystore's keypool.
ThreadCleanWalletPassphrase : re-locks an encrypted wallet after user has unlocked it for a period of time.
SendingDialogStartTransfer : used by pay-via-ip-address code (obsolete)
ThreadDelayedRepaint : repaint the gui
ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
ThreadRPCServer : Remote procedure call handler, listens on port 8332 for connections and services them.
Error(strprintf(_("This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds"),FormatMoney(nFeeRequired).c_str()));
Error(strprintf(_("This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds"),FormatMoney(nFeeRequired).c_str()));
Error(_("The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."));
Error(_("The transaction was rejected. This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."));
return;
}
// Send payment tx to seller, with response going to OnReply3 via event handler
strError=strprintf(_("Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds "),FormatMoney(nFeeRequired).c_str());
strError=strprintf(_("Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds "),FormatMoney(nFeeRequired).c_str());