2011-08-09 04:27:58 -07:00
// Copyright (c) 2009-2010 Satoshi Nakamoto
2013-10-20 12:25:06 -07:00
// Copyright (c) 2009-2013 The Bitcoin developers
2011-06-26 10:23:24 -07:00
// Distributed under the MIT/X11 software license, see the accompanying
2012-05-18 07:02:28 -07:00
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
2011-06-26 10:23:24 -07:00
2012-04-15 14:39:49 -07:00
# include "wallet.h"
2013-04-12 22:13:08 -07:00
2012-05-14 14:44:52 -07:00
# include "base58.h"
2013-04-12 22:13:08 -07:00
# include "net.h"
# include <inttypes.h>
# include <stdint.h>
2012-11-03 07:58:41 -07:00
# include <boost/algorithm/string/replace.hpp>
2013-04-12 22:13:08 -07:00
# include <openssl/rand.h>
2011-06-26 10:23:24 -07:00
using namespace std ;
//////////////////////////////////////////////////////////////////////////////
//
// mapWallet
//
2012-04-07 12:45:39 -07:00
struct CompareValueOnly
{
2013-04-12 22:13:08 -07:00
bool operator ( ) ( const pair < int64_t , pair < const CWalletTx * , unsigned int > > & t1 ,
const pair < int64_t , pair < const CWalletTx * , unsigned int > > & t2 ) const
2012-04-07 12:45:39 -07:00
{
return t1 . first < t2 . first ;
}
} ;
2012-05-14 10:07:52 -07:00
CPubKey CWallet : : GenerateNewKey ( )
2012-02-18 06:02:36 -08:00
{
2012-03-21 19:56:31 -07:00
bool fCompressed = CanSupportFeature ( FEATURE_COMPRPUBKEY ) ; // default to compressed public keys if we want 0.6.0 wallets
2012-02-18 06:06:32 -08:00
2012-02-18 06:02:36 -08:00
RandAddSeedPerfmon ( ) ;
2013-04-30 21:52:05 -07:00
CKey secret ;
secret . MakeNewKey ( fCompressed ) ;
2012-02-18 06:06:32 -08:00
// Compressed public keys were introduced in version 0.6.0
if ( fCompressed )
2012-03-21 19:56:31 -07:00
SetMinVersion ( FEATURE_COMPRPUBKEY ) ;
2012-02-18 06:06:32 -08:00
2013-04-30 21:52:05 -07:00
CPubKey pubkey = secret . GetPubKey ( ) ;
2013-06-19 16:13:55 -07:00
// Create new metadata
2013-04-12 22:13:08 -07:00
int64_t nCreationTime = GetTime ( ) ;
2013-06-19 16:13:55 -07:00
mapKeyMetadata [ pubkey . GetID ( ) ] = CKeyMetadata ( nCreationTime ) ;
if ( ! nTimeFirstKey | | nCreationTime < nTimeFirstKey )
nTimeFirstKey = nCreationTime ;
2013-04-30 21:52:05 -07:00
if ( ! AddKeyPubKey ( secret , pubkey ) )
2012-02-18 06:02:36 -08:00
throw std : : runtime_error ( " CWallet::GenerateNewKey() : AddKey failed " ) ;
2013-04-30 21:52:05 -07:00
return pubkey ;
2012-02-18 06:02:36 -08:00
}
2011-06-26 10:23:24 -07:00
2013-06-19 16:13:55 -07:00
bool CWallet : : AddKeyPubKey ( const CKey & secret , const CPubKey & pubkey )
2011-06-26 10:23:24 -07:00
{
2013-04-30 21:52:05 -07:00
if ( ! CCryptoKeyStore : : AddKeyPubKey ( secret , pubkey ) )
2011-06-25 05:57:32 -07:00
return false ;
2011-06-26 10:23:24 -07:00
if ( ! fFileBacked )
return true ;
2013-04-30 21:52:05 -07:00
if ( ! IsCrypted ( ) ) {
2013-06-10 06:36:29 -07:00
return CWalletDB ( strWalletFile ) . WriteKey ( pubkey ,
secret . GetPrivKey ( ) ,
2013-06-19 16:13:55 -07:00
mapKeyMetadata [ pubkey . GetID ( ) ] ) ;
2013-04-30 21:52:05 -07:00
}
2011-07-13 04:43:50 -07:00
return true ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
}
2013-06-10 06:36:29 -07:00
bool CWallet : : AddCryptedKey ( const CPubKey & vchPubKey ,
2013-06-19 16:13:55 -07:00
const vector < unsigned char > & vchCryptedSecret )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
if ( ! CCryptoKeyStore : : AddCryptedKey ( vchPubKey , vchCryptedSecret ) )
return false ;
if ( ! fFileBacked )
return true ;
2011-07-08 06:08:27 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-07-08 06:08:27 -07:00
if ( pwalletdbEncryption )
2013-06-10 06:36:29 -07:00
return pwalletdbEncryption - > WriteCryptedKey ( vchPubKey ,
vchCryptedSecret ,
2013-06-19 16:13:55 -07:00
mapKeyMetadata [ vchPubKey . GetID ( ) ] ) ;
2011-07-08 06:08:27 -07:00
else
2013-06-10 06:36:29 -07:00
return CWalletDB ( strWalletFile ) . WriteCryptedKey ( vchPubKey ,
vchCryptedSecret ,
2013-06-19 16:13:55 -07:00
mapKeyMetadata [ vchPubKey . GetID ( ) ] ) ;
2011-07-08 06:08:27 -07:00
}
2011-10-10 12:51:07 -07:00
return false ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
}
2013-06-19 16:13:55 -07:00
bool CWallet : : LoadKeyMetadata ( const CPubKey & pubkey , const CKeyMetadata & meta )
{
if ( meta . nCreateTime & & ( ! nTimeFirstKey | | meta . nCreateTime < nTimeFirstKey ) )
nTimeFirstKey = meta . nCreateTime ;
mapKeyMetadata [ pubkey . GetID ( ) ] = meta ;
return true ;
}
2013-05-02 09:43:07 -07:00
bool CWallet : : LoadCryptedKey ( const CPubKey & vchPubKey , const std : : vector < unsigned char > & vchCryptedSecret )
{
return CCryptoKeyStore : : AddCryptedKey ( vchPubKey , vchCryptedSecret ) ;
}
2012-01-04 18:40:52 -08:00
bool CWallet : : AddCScript ( const CScript & redeemScript )
2011-10-03 10:05:43 -07:00
{
2012-01-04 18:40:52 -08:00
if ( ! CCryptoKeyStore : : AddCScript ( redeemScript ) )
2011-10-03 10:05:43 -07:00
return false ;
if ( ! fFileBacked )
return true ;
2012-01-04 18:40:52 -08:00
return CWalletDB ( strWalletFile ) . WriteCScript ( Hash160 ( redeemScript ) , redeemScript ) ;
2011-10-03 10:05:43 -07:00
}
2011-11-25 22:02:04 -08:00
bool CWallet : : Unlock ( const SecureString & strWalletPassphrase )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
2011-08-26 11:37:23 -07:00
CCrypter crypter ;
CKeyingMaterial vMasterKey ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2012-04-06 09:39:12 -07:00
{
LOCK ( cs_wallet ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
BOOST_FOREACH ( const MasterKeyMap : : value_type & pMasterKey , mapMasterKeys )
{
if ( ! crypter . SetKeyFromPassphrase ( strWalletPassphrase , pMasterKey . second . vchSalt , pMasterKey . second . nDeriveIterations , pMasterKey . second . nDerivationMethod ) )
return false ;
if ( ! crypter . Decrypt ( pMasterKey . second . vchCryptedKey , vMasterKey ) )
2013-05-07 07:47:00 -07:00
continue ; // try another master key
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( CCryptoKeyStore : : Unlock ( vMasterKey ) )
return true ;
}
2012-04-06 09:39:12 -07:00
}
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
return false ;
}
2011-11-25 22:02:04 -08:00
bool CWallet : : ChangeWalletPassphrase ( const SecureString & strOldWalletPassphrase , const SecureString & strNewWalletPassphrase )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
2011-08-26 11:37:23 -07:00
bool fWasLocked = IsLocked ( ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
Lock ( ) ;
CCrypter crypter ;
CKeyingMaterial vMasterKey ;
BOOST_FOREACH ( MasterKeyMap : : value_type & pMasterKey , mapMasterKeys )
{
if ( ! crypter . SetKeyFromPassphrase ( strOldWalletPassphrase , pMasterKey . second . vchSalt , pMasterKey . second . nDeriveIterations , pMasterKey . second . nDerivationMethod ) )
return false ;
2011-08-26 11:37:23 -07:00
if ( ! crypter . Decrypt ( pMasterKey . second . vchCryptedKey , vMasterKey ) )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
return false ;
if ( CCryptoKeyStore : : Unlock ( vMasterKey ) )
{
2013-04-12 22:13:08 -07:00
int64_t nStartTime = GetTimeMillis ( ) ;
2011-06-28 06:31:09 -07:00
crypter . SetKeyFromPassphrase ( strNewWalletPassphrase , pMasterKey . second . vchSalt , pMasterKey . second . nDeriveIterations , pMasterKey . second . nDerivationMethod ) ;
pMasterKey . second . nDeriveIterations = pMasterKey . second . nDeriveIterations * ( 100 / ( ( double ) ( GetTimeMillis ( ) - nStartTime ) ) ) ;
nStartTime = GetTimeMillis ( ) ;
crypter . SetKeyFromPassphrase ( strNewWalletPassphrase , pMasterKey . second . vchSalt , pMasterKey . second . nDeriveIterations , pMasterKey . second . nDerivationMethod ) ;
pMasterKey . second . nDeriveIterations = ( pMasterKey . second . nDeriveIterations + pMasterKey . second . nDeriveIterations * 100 / ( ( double ) ( GetTimeMillis ( ) - nStartTime ) ) ) / 2 ;
if ( pMasterKey . second . nDeriveIterations < 25000 )
pMasterKey . second . nDeriveIterations = 25000 ;
2013-09-18 03:38:08 -07:00
LogPrintf ( " Wallet passphrase changed to an nDeriveIterations of %i \n " , pMasterKey . second . nDeriveIterations ) ;
2011-06-28 06:31:09 -07:00
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( ! crypter . SetKeyFromPassphrase ( strNewWalletPassphrase , pMasterKey . second . vchSalt , pMasterKey . second . nDeriveIterations , pMasterKey . second . nDerivationMethod ) )
return false ;
if ( ! crypter . Encrypt ( vMasterKey , pMasterKey . second . vchCryptedKey ) )
return false ;
CWalletDB ( strWalletFile ) . WriteMasterKey ( pMasterKey . first , pMasterKey . second ) ;
if ( fWasLocked )
Lock ( ) ;
return true ;
}
}
}
2011-08-26 11:37:23 -07:00
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
return false ;
}
2012-04-15 13:10:54 -07:00
void CWallet : : SetBestChain ( const CBlockLocator & loc )
{
CWalletDB walletdb ( strWalletFile ) ;
walletdb . WriteBestBlock ( loc ) ;
}
2011-07-10 07:07:22 -07:00
// This class implements an addrIncoming entry that causes pre-0.4
// clients to crash on startup if reading a private-key-encrypted wallet.
class CCorruptAddress
{
public :
IMPLEMENT_SERIALIZE
(
if ( nType & SER_DISK )
READWRITE ( nVersion ) ;
)
} ;
2012-03-21 19:56:31 -07:00
bool CWallet : : SetMinVersion ( enum WalletFeature nVersion , CWalletDB * pwalletdbIn , bool fExplicit )
2012-02-18 05:55:02 -08:00
{
if ( nWalletVersion > = nVersion )
return true ;
2012-03-21 19:56:31 -07:00
// when doing an explicit upgrade, if we pass the max version permitted, upgrade all the way
if ( fExplicit & & nVersion > nWalletMaxVersion )
nVersion = FEATURE_LATEST ;
2012-02-18 05:55:02 -08:00
nWalletVersion = nVersion ;
2012-03-21 19:56:31 -07:00
if ( nVersion > nWalletMaxVersion )
nWalletMaxVersion = nVersion ;
2012-02-18 05:55:02 -08:00
if ( fFileBacked )
{
CWalletDB * pwalletdb = pwalletdbIn ? pwalletdbIn : new CWalletDB ( strWalletFile ) ;
if ( nWalletVersion > = 40000 )
{
// Versions prior to 0.4.0 did not support the "minversion" record.
// Use a CCorruptAddress to make them crash instead.
CCorruptAddress corruptAddress ;
pwalletdb - > WriteSetting ( " addrIncoming " , corruptAddress ) ;
}
if ( nWalletVersion > 40000 )
pwalletdb - > WriteMinVersion ( nWalletVersion ) ;
if ( ! pwalletdbIn )
delete pwalletdb ;
}
return true ;
}
2012-03-21 19:56:31 -07:00
bool CWallet : : SetMaxVersion ( int nVersion )
{
// cannot downgrade below current version
if ( nWalletVersion > nVersion )
return false ;
nWalletMaxVersion = nVersion ;
return true ;
}
2011-11-25 22:02:04 -08:00
bool CWallet : : EncryptWallet ( const SecureString & strWalletPassphrase )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
2011-08-26 11:37:23 -07:00
if ( IsCrypted ( ) )
return false ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
CKeyingMaterial vMasterKey ;
RandAddSeedPerfmon ( ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
vMasterKey . resize ( WALLET_CRYPTO_KEY_SIZE ) ;
RAND_bytes ( & vMasterKey [ 0 ] , WALLET_CRYPTO_KEY_SIZE ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
CMasterKey kMasterKey ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
RandAddSeedPerfmon ( ) ;
kMasterKey . vchSalt . resize ( WALLET_CRYPTO_SALT_SIZE ) ;
RAND_bytes ( & kMasterKey . vchSalt [ 0 ] , WALLET_CRYPTO_SALT_SIZE ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
CCrypter crypter ;
2013-04-12 22:13:08 -07:00
int64_t nStartTime = GetTimeMillis ( ) ;
2011-08-26 11:37:23 -07:00
crypter . SetKeyFromPassphrase ( strWalletPassphrase , kMasterKey . vchSalt , 25000 , kMasterKey . nDerivationMethod ) ;
kMasterKey . nDeriveIterations = 2500000 / ( ( double ) ( GetTimeMillis ( ) - nStartTime ) ) ;
2011-06-28 06:31:09 -07:00
2011-08-26 11:37:23 -07:00
nStartTime = GetTimeMillis ( ) ;
crypter . SetKeyFromPassphrase ( strWalletPassphrase , kMasterKey . vchSalt , kMasterKey . nDeriveIterations , kMasterKey . nDerivationMethod ) ;
kMasterKey . nDeriveIterations = ( kMasterKey . nDeriveIterations + kMasterKey . nDeriveIterations * 100 / ( ( double ) ( GetTimeMillis ( ) - nStartTime ) ) ) / 2 ;
2011-06-28 06:31:09 -07:00
2011-08-26 11:37:23 -07:00
if ( kMasterKey . nDeriveIterations < 25000 )
kMasterKey . nDeriveIterations = 25000 ;
2011-06-28 06:31:09 -07:00
2013-09-18 03:38:08 -07:00
LogPrintf ( " Encrypting Wallet with an nDeriveIterations of %i \n " , kMasterKey . nDeriveIterations ) ;
2011-06-28 06:31:09 -07:00
2011-08-26 11:37:23 -07:00
if ( ! crypter . SetKeyFromPassphrase ( strWalletPassphrase , kMasterKey . vchSalt , kMasterKey . nDeriveIterations , kMasterKey . nDerivationMethod ) )
return false ;
if ( ! crypter . Encrypt ( vMasterKey , kMasterKey . vchCryptedKey ) )
return false ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-08-26 11:37:23 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
mapMasterKeys [ + + nMasterKeyMaxID ] = kMasterKey ;
if ( fFileBacked )
{
2011-07-08 06:08:27 -07:00
pwalletdbEncryption = new CWalletDB ( strWalletFile ) ;
2012-05-13 22:11:11 -07:00
if ( ! pwalletdbEncryption - > TxnBegin ( ) )
return false ;
2011-07-08 06:08:27 -07:00
pwalletdbEncryption - > WriteMasterKey ( nMasterKeyMaxID , kMasterKey ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
}
if ( ! EncryptKeys ( vMasterKey ) )
2011-07-08 06:08:27 -07:00
{
if ( fFileBacked )
pwalletdbEncryption - > TxnAbort ( ) ;
exit ( 1 ) ; //We now probably have half of our keys encrypted in memory, and half not...die and let the user reload their unencrypted wallet.
}
2012-02-18 05:55:02 -08:00
// Encryption was introduced in version 0.4.0
2012-03-21 19:56:31 -07:00
SetMinVersion ( FEATURE_WALLETCRYPT , pwalletdbEncryption , true ) ;
2012-02-18 05:55:02 -08:00
2011-07-08 06:08:27 -07:00
if ( fFileBacked )
{
if ( ! pwalletdbEncryption - > TxnCommit ( ) )
exit ( 1 ) ; //We now have keys encrypted in memory, but no on disk...die to avoid confusion and let the user reload their unencrypted wallet.
2012-02-18 06:36:40 -08:00
delete pwalletdbEncryption ;
2011-07-08 06:08:27 -07:00
pwalletdbEncryption = NULL ;
}
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
2011-11-17 11:01:25 -08:00
Lock ( ) ;
Unlock ( strWalletPassphrase ) ;
NewKeyPool ( ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
Lock ( ) ;
2011-08-26 11:37:23 -07:00
2011-11-10 18:12:46 -08:00
// Need to completely rewrite the wallet file; if we don't, bdb might keep
// bits of the unencrypted private key in slack space in the database file.
2011-11-20 07:39:01 -08:00
CDB : : Rewrite ( strWalletFile ) ;
2012-05-05 07:07:14 -07:00
2011-11-10 18:12:46 -08:00
}
2012-05-06 10:40:58 -07:00
NotifyStatusChanged ( this ) ;
2011-11-10 12:29:23 -08:00
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
return true ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : IncOrderPosNext ( CWalletDB * pwalletdb )
2012-09-07 21:55:36 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nRet = nOrderPosNext + + ;
2012-11-13 14:52:37 -08:00
if ( pwalletdb ) {
pwalletdb - > WriteOrderPosNext ( nOrderPosNext ) ;
} else {
CWalletDB ( strWalletFile ) . WriteOrderPosNext ( nOrderPosNext ) ;
}
2012-09-07 21:55:36 -07:00
return nRet ;
}
2012-09-01 15:07:47 -07:00
CWallet : : TxItems CWallet : : OrderedTxItems ( std : : list < CAccountingEntry > & acentries , std : : string strAccount )
2012-05-28 11:45:12 -07:00
{
CWalletDB walletdb ( strWalletFile ) ;
// First: get all CWalletTx and CAccountingEntry into a sorted-by-order multimap.
TxItems txOrdered ;
// Note: maintaining indices in the database of (account,time) --> txid and (account, time) --> acentry
// would make this much faster for applications that do this a lot.
for ( map < uint256 , CWalletTx > : : iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; + + it )
{
CWalletTx * wtx = & ( ( * it ) . second ) ;
txOrdered . insert ( make_pair ( wtx - > nOrderPos , TxPair ( wtx , ( CAccountingEntry * ) 0 ) ) ) ;
}
2012-09-01 15:07:47 -07:00
acentries . clear ( ) ;
2012-05-28 11:45:12 -07:00
walletdb . ListAccountCreditDebit ( strAccount , acentries ) ;
BOOST_FOREACH ( CAccountingEntry & entry , acentries )
{
txOrdered . insert ( make_pair ( entry . nOrderPos , TxPair ( ( CWalletTx * ) 0 , & entry ) ) ) ;
}
return txOrdered ;
}
2011-06-26 10:23:24 -07:00
void CWallet : : WalletUpdateSpent ( const CTransaction & tx )
{
// Anytime a signature is successfully verified, it's proof the outpoint is spent.
// Update the wallet spent flag if it doesn't know due to wallet.dat being
// restored from backup or the user making copies of wallet.dat.
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( const CTxIn & txin , tx . vin )
{
map < uint256 , CWalletTx > : : iterator mi = mapWallet . find ( txin . prevout . hash ) ;
if ( mi ! = mapWallet . end ( ) )
{
CWalletTx & wtx = ( * mi ) . second ;
2012-09-18 11:30:47 -07:00
if ( txin . prevout . n > = wtx . vout . size ( ) )
2013-09-18 03:38:08 -07:00
LogPrintf ( " WalletUpdateSpent: bad wtx %s \n " , wtx . GetHash ( ) . ToString ( ) . c_str ( ) ) ;
2012-09-18 11:30:47 -07:00
else if ( ! wtx . IsSpent ( txin . prevout . n ) & & IsMine ( wtx . vout [ txin . prevout . n ] ) )
2011-06-26 10:23:24 -07:00
{
2013-09-18 03:38:08 -07:00
LogPrintf ( " WalletUpdateSpent found spent coin %sbc %s \n " , FormatMoney ( wtx . GetCredit ( ) ) . c_str ( ) , wtx . GetHash ( ) . ToString ( ) . c_str ( ) ) ;
2011-06-26 10:23:24 -07:00
wtx . MarkSpent ( txin . prevout . n ) ;
wtx . WriteToDisk ( ) ;
2012-05-05 07:07:14 -07:00
NotifyTransactionChanged ( this , txin . prevout . hash , CT_UPDATED ) ;
2011-06-26 10:23:24 -07:00
}
}
}
}
}
2011-07-13 02:56:38 -07:00
void CWallet : : MarkDirty ( )
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-07-13 02:56:38 -07:00
BOOST_FOREACH ( PAIRTYPE ( const uint256 , CWalletTx ) & item , mapWallet )
item . second . MarkDirty ( ) ;
}
}
2011-06-26 10:23:24 -07:00
bool CWallet : : AddToWallet ( const CWalletTx & wtxIn )
{
uint256 hash = wtxIn . GetHash ( ) ;
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
// Inserts only if not already there, returns tx inserted or tx found
pair < map < uint256 , CWalletTx > : : iterator , bool > ret = mapWallet . insert ( make_pair ( hash , wtxIn ) ) ;
CWalletTx & wtx = ( * ret . first ) . second ;
2011-06-28 14:45:22 -07:00
wtx . BindWallet ( this ) ;
2011-06-26 10:23:24 -07:00
bool fInsertedNew = ret . second ;
if ( fInsertedNew )
2012-05-27 16:06:09 -07:00
{
2011-06-26 10:23:24 -07:00
wtx . nTimeReceived = GetAdjustedTime ( ) ;
2012-09-07 21:55:36 -07:00
wtx . nOrderPos = IncOrderPosNext ( ) ;
2012-05-28 11:45:12 -07:00
wtx . nTimeSmart = wtx . nTimeReceived ;
if ( wtxIn . hashBlock ! = 0 )
{
if ( mapBlockIndex . count ( wtxIn . hashBlock ) )
{
unsigned int latestNow = wtx . nTimeReceived ;
unsigned int latestEntry = 0 ;
{
// Tolerate times up to the last timestamp in the wallet not more than 5 minutes into the future
2013-04-12 22:13:08 -07:00
int64_t latestTolerated = latestNow + 300 ;
2012-09-01 15:07:47 -07:00
std : : list < CAccountingEntry > acentries ;
TxItems txOrdered = OrderedTxItems ( acentries ) ;
2012-05-28 11:45:12 -07:00
for ( TxItems : : reverse_iterator it = txOrdered . rbegin ( ) ; it ! = txOrdered . rend ( ) ; + + it )
{
CWalletTx * const pwtx = ( * it ) . second . first ;
if ( pwtx = = & wtx )
continue ;
CAccountingEntry * const pacentry = ( * it ) . second . second ;
2013-04-12 22:13:08 -07:00
int64_t nSmartTime ;
2012-05-28 11:45:12 -07:00
if ( pwtx )
{
nSmartTime = pwtx - > nTimeSmart ;
if ( ! nSmartTime )
nSmartTime = pwtx - > nTimeReceived ;
}
else
nSmartTime = pacentry - > nTime ;
if ( nSmartTime < = latestTolerated )
{
latestEntry = nSmartTime ;
if ( nSmartTime > latestNow )
latestNow = nSmartTime ;
break ;
}
}
}
unsigned int & blocktime = mapBlockIndex [ wtxIn . hashBlock ] - > nTime ;
wtx . nTimeSmart = std : : max ( latestEntry , std : : min ( blocktime , latestNow ) ) ;
}
else
2013-09-18 03:38:08 -07:00
LogPrintf ( " AddToWallet() : found %s in block %s not in index \n " ,
wtxIn . GetHash ( ) . ToString ( ) . c_str ( ) ,
wtxIn . hashBlock . ToString ( ) . c_str ( ) ) ;
2012-05-28 11:45:12 -07:00
}
2012-05-27 16:06:09 -07:00
}
2011-06-26 10:23:24 -07:00
bool fUpdated = false ;
if ( ! fInsertedNew )
{
// Merge
if ( wtxIn . hashBlock ! = 0 & & wtxIn . hashBlock ! = wtx . hashBlock )
{
wtx . hashBlock = wtxIn . hashBlock ;
fUpdated = true ;
}
if ( wtxIn . nIndex ! = - 1 & & ( wtxIn . vMerkleBranch ! = wtx . vMerkleBranch | | wtxIn . nIndex ! = wtx . nIndex ) )
{
wtx . vMerkleBranch = wtxIn . vMerkleBranch ;
wtx . nIndex = wtxIn . nIndex ;
fUpdated = true ;
}
if ( wtxIn . fFromMe & & wtxIn . fFromMe ! = wtx . fFromMe )
{
wtx . fFromMe = wtxIn . fFromMe ;
fUpdated = true ;
}
fUpdated | = wtx . UpdateSpent ( wtxIn . vfSpent ) ;
}
//// debug print
2013-09-18 03:38:08 -07:00
LogPrintf ( " AddToWallet %s %s%s \n " , wtxIn . GetHash ( ) . ToString ( ) . c_str ( ) , ( fInsertedNew ? " new " : " " ) , ( fUpdated ? " update " : " " ) ) ;
2011-06-26 10:23:24 -07:00
// Write to disk
if ( fInsertedNew | | fUpdated )
if ( ! wtx . WriteToDisk ( ) )
return false ;
2013-05-26 11:17:18 -07:00
2011-06-26 10:23:24 -07:00
// since AddToWallet is called directly for self-originating transactions, check for consumption of own coins
WalletUpdateSpent ( wtx ) ;
2012-05-05 07:07:14 -07:00
// Notify UI of new or updated transaction
NotifyTransactionChanged ( this , hash , fInsertedNew ? CT_NEW : CT_UPDATED ) ;
2012-11-03 07:58:41 -07:00
// notify an external script when a wallet transaction comes in or is updated
std : : string strCmd = GetArg ( " -walletnotify " , " " ) ;
if ( ! strCmd . empty ( ) )
{
boost : : replace_all ( strCmd , " %s " , wtxIn . GetHash ( ) . GetHex ( ) ) ;
boost : : thread t ( runCommand , strCmd ) ; // thread runs free
}
2012-05-05 07:07:14 -07:00
}
2011-06-26 10:23:24 -07:00
return true ;
}
2011-11-06 15:05:42 -08:00
// Add a transaction to the wallet, or update it.
// pblock is optional, but should be provided if the transaction is known to be in a block.
// If fUpdate is true, existing transactions will be updated.
2013-10-19 09:34:06 -07:00
bool CWallet : : AddToWalletIfInvolvingMe ( const uint256 & hash , const CTransaction & tx , const CBlock * pblock , bool fUpdate )
2011-06-26 10:23:24 -07:00
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-08-26 11:37:23 -07:00
bool fExisted = mapWallet . count ( hash ) ;
if ( fExisted & & ! fUpdate ) return false ;
if ( fExisted | | IsMine ( tx ) | | IsFromMe ( tx ) )
{
CWalletTx wtx ( this , tx ) ;
// Get merkle branch if transaction was found in a block
if ( pblock )
wtx . SetMerkleBranch ( pblock ) ;
return AddToWallet ( wtx ) ;
}
else
WalletUpdateSpent ( tx ) ;
2011-06-26 10:23:24 -07:00
}
return false ;
}
2013-10-19 09:34:06 -07:00
void CWallet : : SyncTransaction ( const uint256 & hash , const CTransaction & tx , const CBlock * pblock ) {
AddToWalletIfInvolvingMe ( hash , tx , pblock , true ) ;
}
void CWallet : : EraseFromWallet ( const uint256 & hash )
2011-06-26 10:23:24 -07:00
{
if ( ! fFileBacked )
2013-10-19 09:34:06 -07:00
return ;
2011-06-26 10:23:24 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
if ( mapWallet . erase ( hash ) )
CWalletDB ( strWalletFile ) . EraseTx ( hash ) ;
}
2013-10-19 09:34:06 -07:00
return ;
2011-06-26 10:23:24 -07:00
}
bool CWallet : : IsMine ( const CTxIn & txin ) const
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
map < uint256 , CWalletTx > : : const_iterator mi = mapWallet . find ( txin . prevout . hash ) ;
if ( mi ! = mapWallet . end ( ) )
{
const CWalletTx & prev = ( * mi ) . second ;
if ( txin . prevout . n < prev . vout . size ( ) )
if ( IsMine ( prev . vout [ txin . prevout . n ] ) )
return true ;
}
}
return false ;
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : GetDebit ( const CTxIn & txin ) const
2011-06-26 10:23:24 -07:00
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
map < uint256 , CWalletTx > : : const_iterator mi = mapWallet . find ( txin . prevout . hash ) ;
if ( mi ! = mapWallet . end ( ) )
{
const CWalletTx & prev = ( * mi ) . second ;
if ( txin . prevout . n < prev . vout . size ( ) )
if ( IsMine ( prev . vout [ txin . prevout . n ] ) )
return prev . vout [ txin . prevout . n ] . nValue ;
}
}
return 0 ;
}
2011-10-03 10:05:43 -07:00
bool CWallet : : IsChange ( const CTxOut & txout ) const
{
2012-05-14 14:44:52 -07:00
CTxDestination address ;
2011-11-08 10:20:29 -08:00
// TODO: fix handling of 'change' outputs. The assumption is that any
// payment to a TX_PUBKEYHASH that is mine but isn't in the address book
// is change. That assumption is likely to break when we implement multisignature
// wallets that return change back into a multi-signature-protected address;
// a better way of identifying which outputs are 'the send' and which are
// 'the change' will need to be implemented (maybe extend CWalletTx to remember
// which output, if any, was change).
2012-05-14 14:44:52 -07:00
if ( ExtractDestination ( txout . scriptPubKey , address ) & & : : IsMine ( * this , address ) )
2012-04-06 09:39:12 -07:00
{
LOCK ( cs_wallet ) ;
if ( ! mapAddressBook . count ( address ) )
return true ;
}
2011-10-03 10:05:43 -07:00
return false ;
}
2013-04-12 22:13:08 -07:00
int64_t CWalletTx : : GetTxTime ( ) const
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t n = nTimeSmart ;
2012-05-28 11:45:12 -07:00
return n ? n : nTimeReceived ;
2011-06-26 10:23:24 -07:00
}
int CWalletTx : : GetRequestCount ( ) const
{
// Returns -1 if it wasn't being tracked
int nRequests = - 1 ;
{
2012-04-06 09:39:12 -07:00
LOCK ( pwallet - > cs_wallet ) ;
2011-06-26 10:23:24 -07:00
if ( IsCoinBase ( ) )
{
// Generated block
if ( hashBlock ! = 0 )
{
map < uint256 , int > : : const_iterator mi = pwallet - > mapRequestCount . find ( hashBlock ) ;
if ( mi ! = pwallet - > mapRequestCount . end ( ) )
nRequests = ( * mi ) . second ;
}
}
else
{
// Did anyone request this transaction?
map < uint256 , int > : : const_iterator mi = pwallet - > mapRequestCount . find ( GetHash ( ) ) ;
if ( mi ! = pwallet - > mapRequestCount . end ( ) )
{
nRequests = ( * mi ) . second ;
// How about the block it's in?
if ( nRequests = = 0 & & hashBlock ! = 0 )
{
map < uint256 , int > : : const_iterator mi = pwallet - > mapRequestCount . find ( hashBlock ) ;
if ( mi ! = pwallet - > mapRequestCount . end ( ) )
nRequests = ( * mi ) . second ;
else
nRequests = 1 ; // If it's in someone else's block it must have got out
}
}
}
}
return nRequests ;
}
2013-04-12 22:13:08 -07:00
void CWalletTx : : GetAmounts ( list < pair < CTxDestination , int64_t > > & listReceived ,
list < pair < CTxDestination , int64_t > > & listSent , int64_t & nFee , string & strSentAccount ) const
2011-06-26 10:23:24 -07:00
{
2012-06-01 19:33:28 -07:00
nFee = 0 ;
2011-06-26 10:23:24 -07:00
listReceived . clear ( ) ;
listSent . clear ( ) ;
strSentAccount = strFromAccount ;
// Compute fee:
2013-04-12 22:13:08 -07:00
int64_t nDebit = GetDebit ( ) ;
2011-06-26 10:23:24 -07:00
if ( nDebit > 0 ) // debit>0 means we signed/sent this transaction
{
2013-04-12 22:13:08 -07:00
int64_t nValueOut = GetValueOut ( * this ) ;
2011-06-26 10:23:24 -07:00
nFee = nDebit - nValueOut ;
}
2011-10-03 10:05:43 -07:00
// Sent/received.
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( const CTxOut & txout , vout )
{
2012-09-21 20:20:14 -07:00
bool fIsMine ;
// Only need to handle txouts if AT LEAST one of these is true:
// 1) they debit from us (sent)
// 2) the output is to us (received)
if ( nDebit > 0 )
{
// Don't report 'change' txouts
if ( pwallet - > IsChange ( txout ) )
continue ;
fIsMine = pwallet - > IsMine ( txout ) ;
}
else if ( ! ( fIsMine = pwallet - > IsMine ( txout ) ) )
continue ;
// In either case, we need to get the destination address
2012-05-14 14:44:52 -07:00
CTxDestination address ;
if ( ! ExtractDestination ( txout . scriptPubKey , address ) )
2011-06-26 10:23:24 -07:00
{
2013-09-18 03:38:08 -07:00
LogPrintf ( " CWalletTx::GetAmounts: Unknown transaction type found, txid %s \n " ,
this - > GetHash ( ) . ToString ( ) . c_str ( ) ) ;
2012-09-21 20:20:14 -07:00
address = CNoDestination ( ) ;
2011-06-26 10:23:24 -07:00
}
2012-09-21 20:20:14 -07:00
// If we are debited by the transaction, add the output as a "sent" entry
2011-06-26 10:23:24 -07:00
if ( nDebit > 0 )
listSent . push_back ( make_pair ( address , txout . nValue ) ) ;
2012-09-21 20:20:14 -07:00
// If we are receiving the output, add it as a "received" entry
if ( fIsMine )
2011-06-26 10:23:24 -07:00
listReceived . push_back ( make_pair ( address , txout . nValue ) ) ;
}
}
2013-04-12 22:13:08 -07:00
void CWalletTx : : GetAccountAmounts ( const string & strAccount , int64_t & nReceived ,
int64_t & nSent , int64_t & nFee ) const
2011-06-26 10:23:24 -07:00
{
2012-06-01 19:33:28 -07:00
nReceived = nSent = nFee = 0 ;
2011-06-26 10:23:24 -07:00
2013-04-12 22:13:08 -07:00
int64_t allFee ;
2011-06-26 10:23:24 -07:00
string strSentAccount ;
2013-04-12 22:13:08 -07:00
list < pair < CTxDestination , int64_t > > listReceived ;
list < pair < CTxDestination , int64_t > > listSent ;
2012-06-01 19:33:28 -07:00
GetAmounts ( listReceived , listSent , allFee , strSentAccount ) ;
2011-06-26 10:23:24 -07:00
if ( strAccount = = strSentAccount )
{
2013-04-12 22:13:08 -07:00
BOOST_FOREACH ( const PAIRTYPE ( CTxDestination , int64_t ) & s , listSent )
2011-06-26 10:23:24 -07:00
nSent + = s . second ;
nFee = allFee ;
}
{
2012-04-06 09:39:12 -07:00
LOCK ( pwallet - > cs_wallet ) ;
2013-04-12 22:13:08 -07:00
BOOST_FOREACH ( const PAIRTYPE ( CTxDestination , int64_t ) & r , listReceived )
2011-06-26 10:23:24 -07:00
{
if ( pwallet - > mapAddressBook . count ( r . first ) )
{
2013-07-14 22:20:50 -07:00
map < CTxDestination , CAddressBookData > : : const_iterator mi = pwallet - > mapAddressBook . find ( r . first ) ;
if ( mi ! = pwallet - > mapAddressBook . end ( ) & & ( * mi ) . second . name = = strAccount )
2011-06-26 10:23:24 -07:00
nReceived + = r . second ;
}
else if ( strAccount . empty ( ) )
{
nReceived + = r . second ;
}
}
}
}
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
void CWalletTx : : AddSupportingTransactions ( )
2011-06-26 10:23:24 -07:00
{
vtxPrev . clear ( ) ;
const int COPY_DEPTH = 3 ;
if ( SetMerkleBranch ( ) < COPY_DEPTH )
{
vector < uint256 > vWorkQueue ;
BOOST_FOREACH ( const CTxIn & txin , vin )
vWorkQueue . push_back ( txin . prevout . hash ) ;
{
2012-04-06 09:39:12 -07:00
LOCK ( pwallet - > cs_wallet ) ;
2011-06-26 10:23:24 -07:00
map < uint256 , const CMerkleTx * > mapWalletPrev ;
set < uint256 > setAlreadyDone ;
2012-04-15 13:52:09 -07:00
for ( unsigned int i = 0 ; i < vWorkQueue . size ( ) ; i + + )
2011-06-26 10:23:24 -07:00
{
uint256 hash = vWorkQueue [ i ] ;
if ( setAlreadyDone . count ( hash ) )
continue ;
setAlreadyDone . insert ( hash ) ;
CMerkleTx tx ;
map < uint256 , CWalletTx > : : const_iterator mi = pwallet - > mapWallet . find ( hash ) ;
if ( mi ! = pwallet - > mapWallet . end ( ) )
{
tx = ( * mi ) . second ;
BOOST_FOREACH ( const CMerkleTx & txWalletPrev , ( * mi ) . second . vtxPrev )
mapWalletPrev [ txWalletPrev . GetHash ( ) ] = & txWalletPrev ;
}
else if ( mapWalletPrev . count ( hash ) )
{
tx = * mapWalletPrev [ hash ] ;
}
int nDepth = tx . SetMerkleBranch ( ) ;
vtxPrev . push_back ( tx ) ;
if ( nDepth < COPY_DEPTH )
2012-04-15 04:27:00 -07:00
{
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( const CTxIn & txin , tx . vin )
vWorkQueue . push_back ( txin . prevout . hash ) ;
2012-04-15 04:27:00 -07:00
}
2011-06-26 10:23:24 -07:00
}
}
}
reverse ( vtxPrev . begin ( ) , vtxPrev . end ( ) ) ;
}
2013-10-19 09:42:14 -07:00
bool CWalletTx : : AcceptWalletTransaction ( )
{
{
LOCK ( mempool . cs ) ;
// Add previous supporting transactions first
BOOST_FOREACH ( CMerkleTx & tx , vtxPrev )
{
if ( ! tx . IsCoinBase ( ) )
{
uint256 hash = tx . GetHash ( ) ;
if ( ! mempool . exists ( hash ) & & pcoinsTip - > HaveCoins ( hash ) )
tx . AcceptToMemoryPool ( false ) ;
}
}
return AcceptToMemoryPool ( false ) ;
}
return false ;
}
2011-06-26 10:23:24 -07:00
bool CWalletTx : : WriteToDisk ( )
{
return CWalletDB ( pwallet - > strWalletFile ) . WriteTx ( GetHash ( ) , * this ) ;
}
2011-11-06 15:05:42 -08:00
// Scan the block chain (starting in pindexStart) for transactions
// from or to us. If fUpdate is true, found transactions that already
// exist in the wallet will be updated.
2011-06-26 10:23:24 -07:00
int CWallet : : ScanForWalletTransactions ( CBlockIndex * pindexStart , bool fUpdate )
{
int ret = 0 ;
CBlockIndex * pindex = pindexStart ;
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
while ( pindex )
{
2013-06-10 06:38:13 -07:00
// no need to read and scan block, if block was created before
// our wallet birthday (as adjusted for block time variability)
if ( nTimeFirstKey & & ( pindex - > nTime < ( nTimeFirstKey - 7200 ) ) ) {
2013-10-10 14:07:44 -07:00
pindex = chainActive . Next ( pindex ) ;
2013-06-10 06:38:13 -07:00
continue ;
}
2011-06-26 10:23:24 -07:00
CBlock block ;
2013-06-23 18:10:02 -07:00
ReadBlockFromDisk ( block , pindex ) ;
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( CTransaction & tx , block . vtx )
{
2012-07-07 15:06:34 -07:00
if ( AddToWalletIfInvolvingMe ( tx . GetHash ( ) , tx , & block , fUpdate ) )
2011-06-26 10:23:24 -07:00
ret + + ;
}
2013-10-10 14:07:44 -07:00
pindex = chainActive . Next ( pindex ) ;
2011-06-26 10:23:24 -07:00
}
}
return ret ;
}
void CWallet : : ReacceptWalletTransactions ( )
{
bool fRepeat = true ;
2012-04-06 09:39:12 -07:00
while ( fRepeat )
2011-06-26 10:23:24 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
fRepeat = false ;
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
bool fMissing = false ;
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( PAIRTYPE ( const uint256 , CWalletTx ) & item , mapWallet )
{
CWalletTx & wtx = item . second ;
if ( wtx . IsCoinBase ( ) & & wtx . IsSpent ( 0 ) )
continue ;
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
CCoins coins ;
2011-06-26 10:23:24 -07:00
bool fUpdated = false ;
2012-10-21 06:19:13 -07:00
bool fFound = pcoinsTip - > GetCoins ( wtx . GetHash ( ) , coins ) ;
if ( fFound | | wtx . GetDepthInMainChain ( ) > 0 )
2011-06-26 10:23:24 -07:00
{
// Update fSpent if a tx got spent somewhere else by a copy of wallet.dat
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
for ( unsigned int i = 0 ; i < wtx . vout . size ( ) ; i + + )
2011-06-26 10:23:24 -07:00
{
if ( wtx . IsSpent ( i ) )
continue ;
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
if ( ( i > = coins . vout . size ( ) | | coins . vout [ i ] . IsNull ( ) ) & & IsMine ( wtx . vout [ i ] ) )
2011-06-26 10:23:24 -07:00
{
wtx . MarkSpent ( i ) ;
fUpdated = true ;
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
fMissing = true ;
2011-06-26 10:23:24 -07:00
}
}
if ( fUpdated )
{
2013-09-18 03:38:08 -07:00
LogPrintf ( " ReacceptWalletTransactions found spent coin %sbc %s \n " , FormatMoney ( wtx . GetCredit ( ) ) . c_str ( ) , wtx . GetHash ( ) . ToString ( ) . c_str ( ) ) ;
2011-06-26 10:23:24 -07:00
wtx . MarkDirty ( ) ;
wtx . WriteToDisk ( ) ;
}
}
else
{
2012-07-25 17:48:39 -07:00
// Re-accept any txes of ours that aren't already in a block
2011-06-26 10:23:24 -07:00
if ( ! wtx . IsCoinBase ( ) )
2013-06-13 13:28:03 -07:00
wtx . AcceptWalletTransaction ( ) ;
2011-06-26 10:23:24 -07:00
}
}
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
if ( fMissing )
2011-06-26 10:23:24 -07:00
{
// TODO: optimize this to scan just part of the block chain?
2013-10-10 14:07:44 -07:00
if ( ScanForWalletTransactions ( chainActive . Genesis ( ) ) )
2012-07-25 17:48:39 -07:00
fRepeat = true ; // Found missing transactions: re-do re-accept.
2011-06-26 10:23:24 -07:00
}
}
}
2012-07-06 07:33:34 -07:00
void CWalletTx : : RelayWalletTransaction ( )
2011-06-26 10:23:24 -07:00
{
BOOST_FOREACH ( const CMerkleTx & tx , vtxPrev )
{
2012-08-12 20:26:30 -07:00
if ( ! tx . IsCoinBase ( ) )
2012-11-01 07:52:25 -07:00
if ( tx . GetDepthInMainChain ( ) = = 0 )
2012-08-12 20:26:30 -07:00
RelayTransaction ( ( CTransaction ) tx , tx . GetHash ( ) ) ;
2011-06-26 10:23:24 -07:00
}
if ( ! IsCoinBase ( ) )
{
2012-11-01 07:52:25 -07:00
if ( GetDepthInMainChain ( ) = = 0 ) {
uint256 hash = GetHash ( ) ;
2013-09-18 03:38:08 -07:00
LogPrintf ( " Relaying wtx %s \n " , hash . ToString ( ) . c_str ( ) ) ;
2012-08-12 20:26:30 -07:00
RelayTransaction ( ( CTransaction ) * this , hash ) ;
2011-06-26 10:23:24 -07:00
}
}
}
void CWallet : : ResendWalletTransactions ( )
{
// Do this infrequently and randomly to avoid giving away
// that these are our transactions.
2013-04-19 14:28:25 -07:00
if ( GetTime ( ) < nNextResend )
2011-06-26 10:23:24 -07:00
return ;
2013-04-19 14:28:25 -07:00
bool fFirst = ( nNextResend = = 0 ) ;
nNextResend = GetTime ( ) + GetRand ( 30 * 60 ) ;
2011-06-26 10:23:24 -07:00
if ( fFirst )
return ;
// Only do it if there's been a new block since last time
2013-04-19 14:28:25 -07:00
if ( nTimeBestReceived < nLastResend )
2011-06-26 10:23:24 -07:00
return ;
2013-04-19 14:28:25 -07:00
nLastResend = GetTime ( ) ;
2011-06-26 10:23:24 -07:00
// Rebroadcast any of our txes that aren't in a block yet
2013-09-18 03:38:08 -07:00
LogPrintf ( " ResendWalletTransactions() \n " ) ;
2011-06-26 10:23:24 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
// Sort them in chronological order
multimap < unsigned int , CWalletTx * > mapSorted ;
BOOST_FOREACH ( PAIRTYPE ( const uint256 , CWalletTx ) & item , mapWallet )
{
CWalletTx & wtx = item . second ;
// Don't rebroadcast until it's had plenty of time that
// it should have gotten in already by now.
2013-04-12 22:13:08 -07:00
if ( nTimeBestReceived - ( int64_t ) wtx . nTimeReceived > 5 * 60 )
2011-06-26 10:23:24 -07:00
mapSorted . insert ( make_pair ( wtx . nTimeReceived , & wtx ) ) ;
}
BOOST_FOREACH ( PAIRTYPE ( const unsigned int , CWalletTx * ) & item , mapSorted )
{
CWalletTx & wtx = * item . second ;
2012-07-06 07:33:34 -07:00
wtx . RelayWalletTransaction ( ) ;
2011-06-26 10:23:24 -07:00
}
}
}
//////////////////////////////////////////////////////////////////////////////
//
// Actions
//
2013-04-12 22:13:08 -07:00
int64_t CWallet : : GetBalance ( ) const
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nTotal = 0 ;
2011-06-26 10:23:24 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
for ( map < uint256 , CWalletTx > : : const_iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; + + it )
{
const CWalletTx * pcoin = & ( * it ) . second ;
2013-02-04 11:04:26 -08:00
if ( pcoin - > IsConfirmed ( ) )
2012-02-14 03:08:00 -08:00
nTotal + = pcoin - > GetAvailableCredit ( ) ;
2011-06-26 10:23:24 -07:00
}
}
return nTotal ;
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : GetUnconfirmedBalance ( ) const
2011-07-11 11:42:10 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nTotal = 0 ;
2011-07-11 11:42:10 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-07-11 11:42:10 -07:00
for ( map < uint256 , CWalletTx > : : const_iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; + + it )
{
const CWalletTx * pcoin = & ( * it ) . second ;
2013-01-08 04:17:15 -08:00
if ( ! IsFinalTx ( * pcoin ) | | ! pcoin - > IsConfirmed ( ) )
2012-02-14 03:08:00 -08:00
nTotal + = pcoin - > GetAvailableCredit ( ) ;
}
}
return nTotal ;
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : GetImmatureBalance ( ) const
2012-02-14 03:08:00 -08:00
{
2013-04-12 22:13:08 -07:00
int64_t nTotal = 0 ;
2012-02-14 03:08:00 -08:00
{
LOCK ( cs_wallet ) ;
for ( map < uint256 , CWalletTx > : : const_iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; + + it )
{
2012-06-17 23:32:33 -07:00
const CWalletTx * pcoin = & ( * it ) . second ;
nTotal + = pcoin - > GetImmatureCredit ( ) ;
2011-07-11 11:42:10 -07:00
}
}
return nTotal ;
}
2011-06-26 10:23:24 -07:00
2012-04-12 16:22:15 -07:00
// populate vCoins with vector of spendable COutputs
2012-05-31 13:01:16 -07:00
void CWallet : : AvailableCoins ( vector < COutput > & vCoins , bool fOnlyConfirmed ) const
2012-02-27 04:19:32 -08:00
{
vCoins . clear ( ) ;
{
LOCK ( cs_wallet ) ;
for ( map < uint256 , CWalletTx > : : const_iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; + + it )
{
const CWalletTx * pcoin = & ( * it ) . second ;
2013-01-08 04:17:15 -08:00
if ( ! IsFinalTx ( * pcoin ) )
2012-05-31 13:01:16 -07:00
continue ;
if ( fOnlyConfirmed & & ! pcoin - > IsConfirmed ( ) )
2012-02-27 04:19:32 -08:00
continue ;
if ( pcoin - > IsCoinBase ( ) & & pcoin - > GetBlocksToMaturity ( ) > 0 )
continue ;
2012-09-27 10:52:09 -07:00
for ( unsigned int i = 0 ; i < pcoin - > vout . size ( ) ; i + + ) {
if ( ! ( pcoin - > IsSpent ( i ) ) & & IsMine ( pcoin - > vout [ i ] ) & &
! IsLockedCoin ( ( * it ) . first , i ) & & pcoin - > vout [ i ] . nValue > 0 )
2012-02-27 04:19:32 -08:00
vCoins . push_back ( COutput ( pcoin , i , pcoin - > GetDepthInMainChain ( ) ) ) ;
2012-09-27 10:52:09 -07:00
}
2012-02-27 04:19:32 -08:00
}
}
}
2013-04-12 22:13:08 -07:00
static void ApproximateBestSubset ( vector < pair < int64_t , pair < const CWalletTx * , unsigned int > > > vValue , int64_t nTotalLower , int64_t nTargetValue ,
vector < char > & vfBest , int64_t & nBest , int iterations = 1000 )
2012-04-12 16:22:15 -07:00
{
vector < char > vfIncluded ;
vfBest . assign ( vValue . size ( ) , true ) ;
nBest = nTotalLower ;
2013-02-15 15:27:57 -08:00
seed_insecure_rand ( ) ;
2012-04-12 16:22:15 -07:00
for ( int nRep = 0 ; nRep < iterations & & nBest ! = nTargetValue ; nRep + + )
{
vfIncluded . assign ( vValue . size ( ) , false ) ;
2013-04-12 22:13:08 -07:00
int64_t nTotal = 0 ;
2012-04-12 16:22:15 -07:00
bool fReachedTarget = false ;
for ( int nPass = 0 ; nPass < 2 & & ! fReachedTarget ; nPass + + )
{
for ( unsigned int i = 0 ; i < vValue . size ( ) ; i + + )
{
2013-02-15 15:27:57 -08:00
//The solver here uses a randomized algorithm,
//the randomness serves no real security purpose but is just
//needed to prevent degenerate behavior and it is important
//that the rng fast. We do not use a constant random sequence,
//because there may be some privacy improvement by making
//the selection random.
if ( nPass = = 0 ? insecure_rand ( ) & 1 : ! vfIncluded [ i ] )
2012-04-12 16:22:15 -07:00
{
nTotal + = vValue [ i ] . first ;
vfIncluded [ i ] = true ;
if ( nTotal > = nTargetValue )
{
fReachedTarget = true ;
if ( nTotal < nBest )
{
nBest = nTotal ;
vfBest = vfIncluded ;
}
nTotal - = vValue [ i ] . first ;
vfIncluded [ i ] = false ;
}
}
}
}
}
}
2013-04-12 22:13:08 -07:00
bool CWallet : : SelectCoinsMinConf ( int64_t nTargetValue , int nConfMine , int nConfTheirs , vector < COutput > vCoins ,
set < pair < const CWalletTx * , unsigned int > > & setCoinsRet , int64_t & nValueRet ) const
2011-06-26 10:23:24 -07:00
{
setCoinsRet . clear ( ) ;
nValueRet = 0 ;
// List of values less than target
2013-04-12 22:13:08 -07:00
pair < int64_t , pair < const CWalletTx * , unsigned int > > coinLowestLarger ;
coinLowestLarger . first = std : : numeric_limits < int64_t > : : max ( ) ;
2011-06-26 10:23:24 -07:00
coinLowestLarger . second . first = NULL ;
2013-04-12 22:13:08 -07:00
vector < pair < int64_t , pair < const CWalletTx * , unsigned int > > > vValue ;
int64_t nTotalLower = 0 ;
2011-06-26 10:23:24 -07:00
2012-04-07 10:52:40 -07:00
random_shuffle ( vCoins . begin ( ) , vCoins . end ( ) , GetRandInt ) ;
2012-02-27 04:19:32 -08:00
BOOST_FOREACH ( COutput output , vCoins )
2011-06-26 10:23:24 -07:00
{
2012-02-27 04:19:32 -08:00
const CWalletTx * pcoin = output . tx ;
2011-06-26 10:23:24 -07:00
2012-02-27 04:19:32 -08:00
if ( output . nDepth < ( pcoin - > IsFromMe ( ) ? nConfMine : nConfTheirs ) )
continue ;
2011-06-26 10:23:24 -07:00
2012-02-27 04:19:32 -08:00
int i = output . i ;
2013-04-12 22:13:08 -07:00
int64_t n = pcoin - > vout [ i ] . nValue ;
2011-06-26 10:23:24 -07:00
2013-04-12 22:13:08 -07:00
pair < int64_t , pair < const CWalletTx * , unsigned int > > coin = make_pair ( n , make_pair ( pcoin , i ) ) ;
2011-06-26 10:23:24 -07:00
2012-02-27 04:19:32 -08:00
if ( n = = nTargetValue )
{
setCoinsRet . insert ( coin . second ) ;
nValueRet + = coin . first ;
return true ;
}
else if ( n < nTargetValue + CENT )
{
vValue . push_back ( coin ) ;
nTotalLower + = n ;
}
else if ( n < coinLowestLarger . first )
{
coinLowestLarger = coin ;
2011-06-26 10:23:24 -07:00
}
}
2012-04-12 16:22:15 -07:00
if ( nTotalLower = = nTargetValue )
2011-06-26 10:23:24 -07:00
{
2012-04-15 13:52:09 -07:00
for ( unsigned int i = 0 ; i < vValue . size ( ) ; + + i )
2011-06-26 10:23:24 -07:00
{
setCoinsRet . insert ( vValue [ i ] . second ) ;
nValueRet + = vValue [ i ] . first ;
}
return true ;
}
2012-04-12 16:22:15 -07:00
if ( nTotalLower < nTargetValue )
2011-06-26 10:23:24 -07:00
{
if ( coinLowestLarger . second . first = = NULL )
return false ;
setCoinsRet . insert ( coinLowestLarger . second ) ;
nValueRet + = coinLowestLarger . first ;
return true ;
}
// Solve subset sum by stochastic approximation
2012-04-07 12:45:39 -07:00
sort ( vValue . rbegin ( ) , vValue . rend ( ) , CompareValueOnly ( ) ) ;
2012-04-12 16:22:15 -07:00
vector < char > vfBest ;
2013-04-12 22:13:08 -07:00
int64_t nBest ;
2011-06-26 10:23:24 -07:00
2012-04-12 16:22:15 -07:00
ApproximateBestSubset ( vValue , nTotalLower , nTargetValue , vfBest , nBest , 1000 ) ;
if ( nBest ! = nTargetValue & & nTotalLower > = nTargetValue + CENT )
ApproximateBestSubset ( vValue , nTotalLower , nTargetValue + CENT , vfBest , nBest , 1000 ) ;
2011-06-26 10:23:24 -07:00
2012-04-12 16:22:15 -07:00
// If we have a bigger coin and (either the stochastic approximation didn't find a good solution,
// or the next bigger coin is closer), return the bigger coin
if ( coinLowestLarger . second . first & &
( ( nBest ! = nTargetValue & & nBest < nTargetValue + CENT ) | | coinLowestLarger . first < = nBest ) )
2011-06-26 10:23:24 -07:00
{
setCoinsRet . insert ( coinLowestLarger . second ) ;
nValueRet + = coinLowestLarger . first ;
}
else {
2012-04-15 13:52:09 -07:00
for ( unsigned int i = 0 ; i < vValue . size ( ) ; i + + )
2011-06-26 10:23:24 -07:00
if ( vfBest [ i ] )
{
setCoinsRet . insert ( vValue [ i ] . second ) ;
nValueRet + = vValue [ i ] . first ;
}
2013-09-19 05:47:21 -07:00
LogPrint ( " selectcoins " , " SelectCoins() best subset: " ) ;
2012-04-15 13:52:09 -07:00
for ( unsigned int i = 0 ; i < vValue . size ( ) ; i + + )
2011-06-26 10:23:24 -07:00
if ( vfBest [ i ] )
2013-09-19 05:47:21 -07:00
LogPrint ( " selectcoins " , " %s " , FormatMoney ( vValue [ i ] . first ) . c_str ( ) ) ;
LogPrint ( " selectcoins " , " total %s \n " , FormatMoney ( nBest ) . c_str ( ) ) ;
2011-06-26 10:23:24 -07:00
}
return true ;
}
2013-04-12 22:13:08 -07:00
bool CWallet : : SelectCoins ( int64_t nTargetValue , set < pair < const CWalletTx * , unsigned int > > & setCoinsRet , int64_t & nValueRet ) const
2011-06-26 10:23:24 -07:00
{
2012-02-27 04:19:32 -08:00
vector < COutput > vCoins ;
AvailableCoins ( vCoins ) ;
return ( SelectCoinsMinConf ( nTargetValue , 1 , 6 , vCoins , setCoinsRet , nValueRet ) | |
SelectCoinsMinConf ( nTargetValue , 1 , 1 , vCoins , setCoinsRet , nValueRet ) | |
SelectCoinsMinConf ( nTargetValue , 0 , 1 , vCoins , setCoinsRet , nValueRet ) ) ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
bool CWallet : : CreateTransaction ( const vector < pair < CScript , int64_t > > & vecSend ,
CWalletTx & wtxNew , CReserveKey & reservekey , int64_t & nFeeRet , std : : string & strFailReason )
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nValue = 0 ;
BOOST_FOREACH ( const PAIRTYPE ( CScript , int64_t ) & s , vecSend )
2011-06-26 10:23:24 -07:00
{
if ( nValue < 0 )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Transaction amounts must be positive " ) ;
2011-06-26 10:23:24 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2011-06-26 10:23:24 -07:00
nValue + = s . second ;
}
if ( vecSend . empty ( ) | | nValue < 0 )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Transaction amounts must be positive " ) ;
2011-06-26 10:23:24 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2011-06-26 10:23:24 -07:00
2011-06-28 14:45:22 -07:00
wtxNew . BindWallet ( this ) ;
2011-06-26 10:23:24 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK2 ( cs_main , cs_wallet ) ;
2011-06-26 10:23:24 -07:00
{
nFeeRet = nTransactionFee ;
2013-07-30 21:06:44 -07:00
while ( true )
2011-06-26 10:23:24 -07:00
{
wtxNew . vin . clear ( ) ;
wtxNew . vout . clear ( ) ;
wtxNew . fFromMe = true ;
2013-04-12 22:13:08 -07:00
int64_t nTotalValue = nValue + nFeeRet ;
2011-06-26 10:23:24 -07:00
double dPriority = 0 ;
// vouts to the payees
2013-04-12 22:13:08 -07:00
BOOST_FOREACH ( const PAIRTYPE ( CScript , int64_t ) & s , vecSend )
2013-04-24 15:27:00 -07:00
{
CTxOut txout ( s . second , s . first ) ;
2013-01-08 04:17:15 -08:00
if ( txout . IsDust ( CTransaction : : nMinRelayTxFee ) )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Transaction amount too small " ) ;
2013-04-24 15:27:00 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2013-04-24 15:27:00 -07:00
wtxNew . vout . push_back ( txout ) ;
}
2011-06-26 10:23:24 -07:00
// Choose coins to use
set < pair < const CWalletTx * , unsigned int > > setCoins ;
2013-04-12 22:13:08 -07:00
int64_t nValueIn = 0 ;
2011-06-26 10:23:24 -07:00
if ( ! SelectCoins ( nTotalValue , setCoins , nValueIn ) )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Insufficient funds " ) ;
2011-06-26 10:23:24 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2011-06-26 10:23:24 -07:00
BOOST_FOREACH ( PAIRTYPE ( const CWalletTx * , unsigned int ) pcoin , setCoins )
{
2013-04-12 22:13:08 -07:00
int64_t nCredit = pcoin . first - > vout [ pcoin . second ] . nValue ;
2012-12-26 09:45:42 -08:00
//The priority after the next block (depth+1) is used instead of the current,
//reflecting an assumption the user would accept a bit more delay for
//a chance at a free transaction.
dPriority + = ( double ) nCredit * ( pcoin . first - > GetDepthInMainChain ( ) + 1 ) ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
int64_t nChange = nValueIn - nValue - nFeeRet ;
2013-09-17 18:48:41 -07:00
// The following if statement should be removed once enough miners
// have upgraded to the 0.9 GetMinFee() rules. Until then, this avoids
// creating free transactions that have change outputs less than
// CENT bitcoins.
2013-04-25 17:11:27 -07:00
if ( nFeeRet < CTransaction : : nMinTxFee & & nChange > 0 & & nChange < CENT )
2011-07-24 07:37:09 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nMoveToFee = min ( nChange , CTransaction : : nMinTxFee - nFeeRet ) ;
2011-07-24 07:37:09 -07:00
nChange - = nMoveToFee ;
nFeeRet + = nMoveToFee ;
}
if ( nChange > 0 )
2011-06-26 10:23:24 -07:00
{
// Note: We use a new key here to keep it from being obvious which side is the change.
// The drawback is that by not reusing a previous key, the change may be lost if a
// backup is restored, if the backup doesn't have the new private key for the change.
// If we reused the old key, it would be possible to add code to look for and
// rediscover unknown transactions that were written with keys of ours to recover
// post-backup change.
// Reserve a new key pair from key pool
2013-04-25 10:30:28 -07:00
CPubKey vchPubKey ;
assert ( reservekey . GetReservedKey ( vchPubKey ) ) ; // should never fail, as we just unlocked
2011-06-26 10:23:24 -07:00
2011-09-28 09:30:06 -07:00
// Fill a vout to ourself
// TODO: pass in scriptChange instead of reservekey so
// change transaction isn't always pay-to-bitcoin-address
2011-06-26 10:23:24 -07:00
CScript scriptChange ;
2012-05-14 14:44:52 -07:00
scriptChange . SetDestination ( vchPubKey . GetID ( ) ) ;
2011-06-26 10:23:24 -07:00
2013-04-24 15:27:00 -07:00
CTxOut newTxOut ( nChange , scriptChange ) ;
// Never create dust outputs; if we would, just
// add the dust to the fee.
2013-01-08 04:17:15 -08:00
if ( newTxOut . IsDust ( CTransaction : : nMinRelayTxFee ) )
2013-04-24 15:27:00 -07:00
{
nFeeRet + = nChange ;
reservekey . ReturnKey ( ) ;
}
else
{
// Insert change txn at random position:
vector < CTxOut > : : iterator position = wtxNew . vout . begin ( ) + GetRandInt ( wtxNew . vout . size ( ) + 1 ) ;
wtxNew . vout . insert ( position , newTxOut ) ;
}
2011-06-26 10:23:24 -07:00
}
else
reservekey . ReturnKey ( ) ;
// Fill vin
BOOST_FOREACH ( const PAIRTYPE ( const CWalletTx * , unsigned int ) & coin , setCoins )
wtxNew . vin . push_back ( CTxIn ( coin . first - > GetHash ( ) , coin . second ) ) ;
// Sign
int nIn = 0 ;
BOOST_FOREACH ( const PAIRTYPE ( const CWalletTx * , unsigned int ) & coin , setCoins )
if ( ! SignSignature ( * this , * coin . first , wtxNew , nIn + + ) )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Signing transaction failed " ) ;
2011-06-26 10:23:24 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2011-06-26 10:23:24 -07:00
// Limit size
2012-04-16 05:56:45 -07:00
unsigned int nBytes = : : GetSerializeSize ( * ( CTransaction * ) & wtxNew , SER_NETWORK , PROTOCOL_VERSION ) ;
2013-02-04 13:56:26 -08:00
if ( nBytes > = MAX_STANDARD_TX_SIZE )
2013-04-25 14:31:22 -07:00
{
strFailReason = _ ( " Transaction too large " ) ;
2011-06-26 10:23:24 -07:00
return false ;
2013-04-25 14:31:22 -07:00
}
2013-08-28 02:15:39 -07:00
unsigned int nTxSizeMod = nBytes ;
// See miner.c's dPriority logic for the matching network-node side code.
BOOST_FOREACH ( const CTxIn & txin , ( * ( CTransaction * ) & wtxNew ) . vin )
{
unsigned int offset = 41U + min ( 110U , ( unsigned int ) txin . scriptSig . size ( ) ) ;
if ( nTxSizeMod > offset )
nTxSizeMod - = offset ;
}
dPriority / = nTxSizeMod ;
2011-06-26 10:23:24 -07:00
// Check that enough fee is included
2013-04-12 22:13:08 -07:00
int64_t nPayFee = nTransactionFee * ( 1 + ( int64_t ) nBytes / 1000 ) ;
2013-01-08 04:17:15 -08:00
bool fAllowFree = AllowFree ( dPriority ) ;
2013-04-12 22:13:08 -07:00
int64_t nMinFee = GetMinFee ( wtxNew , fAllowFree , GMF_SEND ) ;
2011-06-26 10:23:24 -07:00
if ( nFeeRet < max ( nPayFee , nMinFee ) )
{
nFeeRet = max ( nPayFee , nMinFee ) ;
continue ;
}
// Fill vtxPrev by copying from previous transactions vtxPrev
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 09:54:00 -07:00
wtxNew . AddSupportingTransactions ( ) ;
2011-06-26 10:23:24 -07:00
wtxNew . fTimeReceivedIsTxTime = true ;
break ;
}
}
}
return true ;
}
2013-04-12 22:13:08 -07:00
bool CWallet : : CreateTransaction ( CScript scriptPubKey , int64_t nValue ,
CWalletTx & wtxNew , CReserveKey & reservekey , int64_t & nFeeRet , std : : string & strFailReason )
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
vector < pair < CScript , int64_t > > vecSend ;
2011-06-26 10:23:24 -07:00
vecSend . push_back ( make_pair ( scriptPubKey , nValue ) ) ;
2013-04-25 14:31:22 -07:00
return CreateTransaction ( vecSend , wtxNew , reservekey , nFeeRet , strFailReason ) ;
2011-06-26 10:23:24 -07:00
}
// Call after CreateTransaction unless you want to abort
bool CWallet : : CommitTransaction ( CWalletTx & wtxNew , CReserveKey & reservekey )
{
{
2012-04-06 09:39:12 -07:00
LOCK2 ( cs_main , cs_wallet ) ;
2013-09-18 03:38:08 -07:00
LogPrintf ( " CommitTransaction: \n %s " , wtxNew . ToString ( ) . c_str ( ) ) ;
2011-06-26 10:23:24 -07:00
{
// This is only to keep the database open to defeat the auto-flush for the
// duration of this scope. This is the only place where this optimization
// maybe makes sense; please don't do it anywhere else.
CWalletDB * pwalletdb = fFileBacked ? new CWalletDB ( strWalletFile , " r " ) : NULL ;
// Take key pair from key pool so it won't be used again
reservekey . KeepKey ( ) ;
// Add tx to wallet, because if it has change it's also ours,
// otherwise just for transaction history.
AddToWallet ( wtxNew ) ;
// Mark old coins as spent
set < CWalletTx * > setCoins ;
BOOST_FOREACH ( const CTxIn & txin , wtxNew . vin )
{
CWalletTx & coin = mapWallet [ txin . prevout . hash ] ;
2011-06-28 14:45:22 -07:00
coin . BindWallet ( this ) ;
2011-06-26 10:23:24 -07:00
coin . MarkSpent ( txin . prevout . n ) ;
coin . WriteToDisk ( ) ;
2012-05-05 07:07:14 -07:00
NotifyTransactionChanged ( this , coin . GetHash ( ) , CT_UPDATED ) ;
2011-06-26 10:23:24 -07:00
}
if ( fFileBacked )
delete pwalletdb ;
}
// Track how many getdata requests our transaction gets
2011-08-26 11:37:23 -07:00
mapRequestCount [ wtxNew . GetHash ( ) ] = 0 ;
2011-06-26 10:23:24 -07:00
// Broadcast
2013-06-13 13:28:03 -07:00
if ( ! wtxNew . AcceptToMemoryPool ( false ) )
2011-06-26 10:23:24 -07:00
{
// This must not fail. The transaction has already been signed and recorded.
2013-09-18 03:38:08 -07:00
LogPrintf ( " CommitTransaction() : Error: Transaction not valid " ) ;
2011-06-26 10:23:24 -07:00
return false ;
}
wtxNew . RelayWalletTransaction ( ) ;
}
return true ;
}
2013-04-12 22:13:08 -07:00
string CWallet : : SendMoney ( CScript scriptPubKey , int64_t nValue , CWalletTx & wtxNew , bool fAskFee )
2011-06-26 10:23:24 -07:00
{
CReserveKey reservekey ( this ) ;
2013-04-12 22:13:08 -07:00
int64_t nFeeRequired ;
2011-08-26 11:37:23 -07:00
if ( IsLocked ( ) )
2011-06-26 10:23:24 -07:00
{
2012-09-18 09:26:02 -07:00
string strError = _ ( " Error: Wallet locked, unable to create transaction! " ) ;
2013-09-18 03:38:08 -07:00
LogPrintf ( " SendMoney() : %s " , strError . c_str ( ) ) ;
2011-08-26 11:37:23 -07:00
return strError ;
}
2013-04-25 14:31:22 -07:00
string strError ;
if ( ! CreateTransaction ( scriptPubKey , nValue , wtxNew , reservekey , nFeeRequired , strError ) )
2011-08-26 11:37:23 -07:00
{
if ( nValue + nFeeRequired > GetBalance ( ) )
2012-09-18 09:26:02 -07:00
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 ( ) ) ;
2013-09-18 03:38:08 -07:00
LogPrintf ( " SendMoney() : %s \n " , strError . c_str ( ) ) ;
2011-08-26 11:37:23 -07:00
return strError ;
2011-06-26 10:23:24 -07:00
}
2012-12-03 04:51:58 -08:00
if ( fAskFee & & ! uiInterface . ThreadSafeAskFee ( nFeeRequired ) )
2011-06-26 10:23:24 -07:00
return " ABORTED " ;
if ( ! CommitTransaction ( wtxNew , reservekey ) )
2012-09-18 09:26:02 -07:00
return _ ( " 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. " ) ;
2011-06-26 10:23:24 -07:00
return " " ;
}
2013-04-12 22:13:08 -07:00
string CWallet : : SendMoneyToDestination ( const CTxDestination & address , int64_t nValue , CWalletTx & wtxNew , bool fAskFee )
2011-06-26 10:23:24 -07:00
{
// Check amount
if ( nValue < = 0 )
return _ ( " Invalid amount " ) ;
if ( nValue + nTransactionFee > GetBalance ( ) )
return _ ( " Insufficient funds " ) ;
2012-05-13 07:09:14 -07:00
// Parse Bitcoin address
2011-06-26 10:23:24 -07:00
CScript scriptPubKey ;
2012-05-14 14:44:52 -07:00
scriptPubKey . SetDestination ( address ) ;
2011-06-26 10:23:24 -07:00
return SendMoney ( scriptPubKey , nValue , wtxNew , fAskFee ) ;
}
2012-09-18 11:30:47 -07:00
DBErrors CWallet : : LoadWallet ( bool & fFirstRunRet )
2011-06-26 10:23:24 -07:00
{
if ( ! fFileBacked )
2012-09-05 01:32:13 -07:00
return DB_LOAD_OK ;
2011-06-26 10:23:24 -07:00
fFirstRunRet = false ;
2012-09-18 11:30:47 -07:00
DBErrors nLoadWalletRet = CWalletDB ( strWalletFile , " cr+ " ) . LoadWallet ( this ) ;
2011-11-10 18:12:46 -08:00
if ( nLoadWalletRet = = DB_NEED_REWRITE )
2011-11-10 12:29:23 -08:00
{
2011-11-10 18:12:46 -08:00
if ( CDB : : Rewrite ( strWalletFile , " \x04 pool " ) )
{
setKeyPool . clear ( ) ;
// Note: can't top-up keypool here, because wallet is locked.
// User will be prompted to unlock wallet the next operation
// the requires a new key.
}
2011-11-10 12:29:23 -08:00
}
2011-07-04 18:06:19 -07:00
if ( nLoadWalletRet ! = DB_LOAD_OK )
return nLoadWalletRet ;
2012-05-14 10:07:52 -07:00
fFirstRunRet = ! vchDefaultKey . IsValid ( ) ;
2011-06-26 10:23:24 -07:00
2011-07-12 22:07:49 -07:00
return DB_LOAD_OK ;
2011-06-26 10:23:24 -07:00
}
2011-07-07 06:22:54 -07:00
2013-07-21 23:50:39 -07:00
bool CWallet : : SetAddressBook ( const CTxDestination & address , const string & strName , const string & strPurpose )
2011-07-07 06:22:54 -07:00
{
2013-07-14 22:20:50 -07:00
std : : map < CTxDestination , CAddressBookData > : : iterator mi = mapAddressBook . find ( address ) ;
mapAddressBook [ address ] . name = strName ;
2013-08-29 07:19:43 -07:00
if ( ! strPurpose . empty ( ) ) /* update purpose only if requested */
mapAddressBook [ address ] . purpose = strPurpose ;
NotifyAddressBookChanged ( this , address , strName , : : IsMine ( * this , address ) ,
mapAddressBook [ address ] . purpose ,
( mi = = mapAddressBook . end ( ) ) ? CT_NEW : CT_UPDATED ) ;
2011-07-07 06:22:54 -07:00
if ( ! fFileBacked )
return false ;
2013-07-21 23:50:39 -07:00
if ( ! strPurpose . empty ( ) & & ! CWalletDB ( strWalletFile ) . WritePurpose ( CBitcoinAddress ( address ) . ToString ( ) , strPurpose ) )
return false ;
2012-05-14 14:44:52 -07:00
return CWalletDB ( strWalletFile ) . WriteName ( CBitcoinAddress ( address ) . ToString ( ) , strName ) ;
2011-07-07 06:22:54 -07:00
}
2013-07-21 23:50:39 -07:00
bool CWallet : : DelAddressBook ( const CTxDestination & address )
2011-07-07 06:22:54 -07:00
{
2011-07-05 11:53:43 -07:00
mapAddressBook . erase ( address ) ;
2013-08-29 07:19:43 -07:00
NotifyAddressBookChanged ( this , address , " " , : : IsMine ( * this , address ) , " " , CT_DELETED ) ;
2011-07-07 06:22:54 -07:00
if ( ! fFileBacked )
return false ;
2013-07-21 23:50:39 -07:00
CWalletDB ( strWalletFile ) . ErasePurpose ( CBitcoinAddress ( address ) . ToString ( ) ) ;
2012-05-14 14:44:52 -07:00
return CWalletDB ( strWalletFile ) . EraseName ( CBitcoinAddress ( address ) . ToString ( ) ) ;
2011-07-07 06:22:54 -07:00
}
2012-05-14 10:07:52 -07:00
bool CWallet : : SetDefaultKey ( const CPubKey & vchPubKey )
2011-07-07 06:22:54 -07:00
{
if ( fFileBacked )
{
if ( ! CWalletDB ( strWalletFile ) . WriteDefaultKey ( vchPubKey ) )
return false ;
}
vchDefaultKey = vchPubKey ;
return true ;
}
2011-11-17 11:01:25 -08:00
//
// Mark old keypool keys as used,
// and generate all new keys
//
bool CWallet : : NewKeyPool ( )
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-11-17 11:01:25 -08:00
CWalletDB walletdb ( strWalletFile ) ;
2013-04-12 22:13:08 -07:00
BOOST_FOREACH ( int64_t nIndex , setKeyPool )
2011-11-17 11:01:25 -08:00
walletdb . ErasePool ( nIndex ) ;
setKeyPool . clear ( ) ;
if ( IsLocked ( ) )
return false ;
2013-04-12 22:13:08 -07:00
int64_t nKeys = max ( GetArg ( " -keypool " , 100 ) , ( int64_t ) 0 ) ;
2011-11-17 11:01:25 -08:00
for ( int i = 0 ; i < nKeys ; i + + )
{
2013-04-12 22:13:08 -07:00
int64_t nIndex = i + 1 ;
2011-11-17 11:01:25 -08:00
walletdb . WritePool ( nIndex , CKeyPool ( GenerateNewKey ( ) ) ) ;
setKeyPool . insert ( nIndex ) ;
}
2013-04-12 22:13:08 -07:00
LogPrintf ( " CWallet::NewKeyPool wrote % " PRId64 " new keys \n " , nKeys ) ;
2011-11-17 11:01:25 -08:00
}
return true ;
}
2013-06-25 13:07:29 -07:00
bool CWallet : : TopUpKeyPool ( unsigned int kpSize )
2011-06-26 10:23:24 -07:00
{
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( IsLocked ( ) )
return false ;
2011-06-26 10:23:24 -07:00
CWalletDB walletdb ( strWalletFile ) ;
// Top up key pool
2013-06-25 13:07:29 -07:00
unsigned int nTargetSize ;
if ( kpSize > 0 )
nTargetSize = kpSize ;
else
2013-04-12 22:13:08 -07:00
nTargetSize = max ( GetArg ( " -keypool " , 100 ) , ( int64_t ) 0 ) ;
2013-06-25 13:07:29 -07:00
2012-04-22 10:22:39 -07:00
while ( setKeyPool . size ( ) < ( nTargetSize + 1 ) )
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nEnd = 1 ;
2011-06-26 10:23:24 -07:00
if ( ! setKeyPool . empty ( ) )
nEnd = * ( - - setKeyPool . end ( ) ) + 1 ;
if ( ! walletdb . WritePool ( nEnd , CKeyPool ( GenerateNewKey ( ) ) ) )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
throw runtime_error ( " TopUpKeyPool() : writing generated key failed " ) ;
2011-06-26 10:23:24 -07:00
setKeyPool . insert ( nEnd ) ;
2013-04-12 22:13:08 -07:00
LogPrintf ( " keypool added key % " PRId64 " , size=% " PRIszu " \n " , nEnd , setKeyPool . size ( ) ) ;
2011-06-26 10:23:24 -07:00
}
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
}
return true ;
}
2013-04-12 22:13:08 -07:00
void CWallet : : ReserveKeyFromKeyPool ( int64_t & nIndex , CKeyPool & keypool )
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
nIndex = - 1 ;
2012-05-14 10:07:52 -07:00
keypool . vchPubKey = CPubKey ( ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( ! IsLocked ( ) )
TopUpKeyPool ( ) ;
2011-06-26 10:23:24 -07:00
// Get the oldest key
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( setKeyPool . empty ( ) )
return ;
CWalletDB walletdb ( strWalletFile ) ;
2011-06-26 10:23:24 -07:00
nIndex = * ( setKeyPool . begin ( ) ) ;
setKeyPool . erase ( setKeyPool . begin ( ) ) ;
if ( ! walletdb . ReadPool ( nIndex , keypool ) )
throw runtime_error ( " ReserveKeyFromKeyPool() : read failed " ) ;
2012-05-14 10:07:52 -07:00
if ( ! HaveKey ( keypool . vchPubKey . GetID ( ) ) )
2011-06-26 10:23:24 -07:00
throw runtime_error ( " ReserveKeyFromKeyPool() : unknown key in key pool " ) ;
2012-05-14 10:07:52 -07:00
assert ( keypool . vchPubKey . IsValid ( ) ) ;
2013-04-12 22:13:08 -07:00
LogPrintf ( " keypool reserve % " PRId64 " \n " , nIndex ) ;
2011-06-26 10:23:24 -07:00
}
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : AddReserveKey ( const CKeyPool & keypool )
2011-07-11 12:49:45 -07:00
{
{
2012-04-06 09:39:12 -07:00
LOCK2 ( cs_main , cs_wallet ) ;
2011-07-11 12:49:45 -07:00
CWalletDB walletdb ( strWalletFile ) ;
2013-04-12 22:13:08 -07:00
int64_t nIndex = 1 + * ( - - setKeyPool . end ( ) ) ;
2011-07-11 12:49:45 -07:00
if ( ! walletdb . WritePool ( nIndex , keypool ) )
throw runtime_error ( " AddReserveKey() : writing added key failed " ) ;
setKeyPool . insert ( nIndex ) ;
return nIndex ;
}
return - 1 ;
}
2013-04-12 22:13:08 -07:00
void CWallet : : KeepKey ( int64_t nIndex )
2011-06-26 10:23:24 -07:00
{
// Remove from key pool
if ( fFileBacked )
{
CWalletDB walletdb ( strWalletFile ) ;
2011-08-26 11:37:23 -07:00
walletdb . ErasePool ( nIndex ) ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
LogPrintf ( " keypool keep % " PRId64 " \n " , nIndex ) ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
void CWallet : : ReturnKey ( int64_t nIndex )
2011-06-26 10:23:24 -07:00
{
// Return to key pool
2012-04-06 09:39:12 -07:00
{
LOCK ( cs_wallet ) ;
2011-06-26 10:23:24 -07:00
setKeyPool . insert ( nIndex ) ;
2012-04-06 09:39:12 -07:00
}
2013-04-12 22:13:08 -07:00
LogPrintf ( " keypool return % " PRId64 " \n " , nIndex ) ;
2011-06-26 10:23:24 -07:00
}
2013-08-23 12:54:50 -07:00
bool CWallet : : GetKeyFromPool ( CPubKey & result )
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nIndex = 0 ;
2011-06-26 10:23:24 -07:00
CKeyPool keypool ;
2011-08-12 13:32:07 -07:00
{
2012-04-06 09:39:12 -07:00
LOCK ( cs_wallet ) ;
2011-09-01 07:58:08 -07:00
ReserveKeyFromKeyPool ( nIndex , keypool ) ;
if ( nIndex = = - 1 )
2011-08-12 13:32:07 -07:00
{
2011-09-01 07:58:08 -07:00
if ( IsLocked ( ) ) return false ;
result = GenerateNewKey ( ) ;
2011-08-12 13:32:07 -07:00
return true ;
}
2011-09-01 07:58:08 -07:00
KeepKey ( nIndex ) ;
result = keypool . vchPubKey ;
2011-08-12 13:32:07 -07:00
}
return true ;
2011-06-26 10:23:24 -07:00
}
2013-04-12 22:13:08 -07:00
int64_t CWallet : : GetOldestKeyPoolTime ( )
2011-06-26 10:23:24 -07:00
{
2013-04-12 22:13:08 -07:00
int64_t nIndex = 0 ;
2011-06-26 10:23:24 -07:00
CKeyPool keypool ;
ReserveKeyFromKeyPool ( nIndex , keypool ) ;
Add wallet privkey encryption.
This commit adds support for ckeys, or enCrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.
Keys are encrypted with AES-256-CBC using OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using SHA512 with (by default) 25000 rounds and
a random salt.
By default, the user's wallet remains unencrypted until they call the RPC
command encryptwallet <passphrase> or, from the GUI menu, Options->
Encrypt Wallet.
When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassphrase <passphrase> <time to keep key in memory> first.
A keypoolrefill command has been added which tops up the users keypool
(requiring the passphrase via walletpassphrase first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their passphrase (and call
keypoolrefill).
Note that walletpassphrase will automatically fill keypool in a separate
thread which it spawns when the passphrase is set. This could cause some
delays in other threads waiting for locks on the wallet passphrase, including
one which could cause the passphrase to be stored longer than expected,
however it will not allow the passphrase to be used longer than expected as
ThreadCleanWalletPassphrase will attempt to get a lock on the key as soon
as the specified lock time has arrived.
When the keypool runs out (and wallet is locked) GetOrReuseKeyFromPool
returns vchDefaultKey, meaning miners may start to generate many blocks to
vchDefaultKey instead of a new key each time.
A walletpassphrasechange <oldpassphrase> <newpassphrase> has been added to
allow the user to change their password via RPC.
Whenever keying material (unencrypted private keys, the user's passphrase,
the wallet's AES key) is stored unencrypted in memory, any reasonable attempt
is made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.
Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.
Thanks to jgarzik for the original patch and sipa, gmaxwell and many others
for all their input.
Conflicts:
src/wallet.cpp
2011-07-08 06:47:35 -07:00
if ( nIndex = = - 1 )
return GetTime ( ) ;
2011-06-26 10:23:24 -07:00
ReturnKey ( nIndex ) ;
return keypool . nTime ;
}
2013-04-12 22:13:08 -07:00
std : : map < CTxDestination , int64_t > CWallet : : GetAddressBalances ( )
2012-08-01 09:48:42 -07:00
{
2013-04-12 22:13:08 -07:00
map < CTxDestination , int64_t > balances ;
2012-08-01 09:48:42 -07:00
{
LOCK ( cs_wallet ) ;
BOOST_FOREACH ( PAIRTYPE ( uint256 , CWalletTx ) walletEntry , mapWallet )
{
CWalletTx * pcoin = & walletEntry . second ;
2013-01-08 04:17:15 -08:00
if ( ! IsFinalTx ( * pcoin ) | | ! pcoin - > IsConfirmed ( ) )
2012-08-01 09:48:42 -07:00
continue ;
if ( pcoin - > IsCoinBase ( ) & & pcoin - > GetBlocksToMaturity ( ) > 0 )
continue ;
int nDepth = pcoin - > GetDepthInMainChain ( ) ;
if ( nDepth < ( pcoin - > IsFromMe ( ) ? 0 : 1 ) )
continue ;
2012-08-20 10:43:33 -07:00
for ( unsigned int i = 0 ; i < pcoin - > vout . size ( ) ; i + + )
2012-08-01 09:48:42 -07:00
{
2012-08-20 10:43:33 -07:00
CTxDestination addr ;
2012-08-01 09:48:42 -07:00
if ( ! IsMine ( pcoin - > vout [ i ] ) )
continue ;
2012-08-20 10:43:33 -07:00
if ( ! ExtractDestination ( pcoin - > vout [ i ] . scriptPubKey , addr ) )
continue ;
2012-08-01 09:48:42 -07:00
2013-04-12 22:13:08 -07:00
int64_t n = pcoin - > IsSpent ( i ) ? 0 : pcoin - > vout [ i ] . nValue ;
2012-08-01 09:48:42 -07:00
if ( ! balances . count ( addr ) )
balances [ addr ] = 0 ;
balances [ addr ] + = n ;
}
}
}
return balances ;
}
2012-08-20 10:43:33 -07:00
set < set < CTxDestination > > CWallet : : GetAddressGroupings ( )
2012-08-01 09:48:42 -07:00
{
2012-08-20 10:43:33 -07:00
set < set < CTxDestination > > groupings ;
set < CTxDestination > grouping ;
2012-08-01 09:48:42 -07:00
BOOST_FOREACH ( PAIRTYPE ( uint256 , CWalletTx ) walletEntry , mapWallet )
{
CWalletTx * pcoin = & walletEntry . second ;
2012-09-27 10:29:35 -07:00
if ( pcoin - > vin . size ( ) > 0 )
2012-08-01 09:48:42 -07:00
{
2012-09-27 10:29:35 -07:00
bool any_mine = false ;
2012-08-01 09:48:42 -07:00
// group all input addresses with each other
BOOST_FOREACH ( CTxIn txin , pcoin - > vin )
2012-08-20 10:43:33 -07:00
{
CTxDestination address ;
2012-09-27 10:29:35 -07:00
if ( ! IsMine ( txin ) ) /* If this input isn't mine, ignore it */
continue ;
2012-08-20 10:43:33 -07:00
if ( ! ExtractDestination ( mapWallet [ txin . prevout . hash ] . vout [ txin . prevout . n ] . scriptPubKey , address ) )
continue ;
grouping . insert ( address ) ;
2012-09-27 10:29:35 -07:00
any_mine = true ;
2012-08-20 10:43:33 -07:00
}
2012-08-01 09:48:42 -07:00
// group change with input addresses
2012-09-27 10:29:35 -07:00
if ( any_mine )
{
BOOST_FOREACH ( CTxOut txout , pcoin - > vout )
if ( IsChange ( txout ) )
{
CTxDestination txoutAddr ;
if ( ! ExtractDestination ( txout . scriptPubKey , txoutAddr ) )
continue ;
grouping . insert ( txoutAddr ) ;
}
}
if ( grouping . size ( ) > 0 )
{
groupings . insert ( grouping ) ;
grouping . clear ( ) ;
}
2012-08-01 09:48:42 -07:00
}
// group lone addrs by themselves
2012-08-20 10:43:33 -07:00
for ( unsigned int i = 0 ; i < pcoin - > vout . size ( ) ; i + + )
2012-08-01 09:48:42 -07:00
if ( IsMine ( pcoin - > vout [ i ] ) )
{
2012-08-20 10:43:33 -07:00
CTxDestination address ;
if ( ! ExtractDestination ( pcoin - > vout [ i ] . scriptPubKey , address ) )
continue ;
grouping . insert ( address ) ;
2012-08-01 09:48:42 -07:00
groupings . insert ( grouping ) ;
grouping . clear ( ) ;
}
}
2012-08-20 10:43:33 -07:00
set < set < CTxDestination > * > uniqueGroupings ; // a set of pointers to groups of addresses
map < CTxDestination , set < CTxDestination > * > setmap ; // map addresses to the unique group containing it
BOOST_FOREACH ( set < CTxDestination > grouping , groupings )
2012-08-01 09:48:42 -07:00
{
// make a set of all the groups hit by this new group
2012-08-20 10:43:33 -07:00
set < set < CTxDestination > * > hits ;
map < CTxDestination , set < CTxDestination > * > : : iterator it ;
BOOST_FOREACH ( CTxDestination address , grouping )
2012-08-01 09:48:42 -07:00
if ( ( it = setmap . find ( address ) ) ! = setmap . end ( ) )
hits . insert ( ( * it ) . second ) ;
// merge all hit groups into a new single group and delete old groups
2012-08-20 10:43:33 -07:00
set < CTxDestination > * merged = new set < CTxDestination > ( grouping ) ;
BOOST_FOREACH ( set < CTxDestination > * hit , hits )
2012-08-01 09:48:42 -07:00
{
merged - > insert ( hit - > begin ( ) , hit - > end ( ) ) ;
uniqueGroupings . erase ( hit ) ;
delete hit ;
}
uniqueGroupings . insert ( merged ) ;
// update setmap
2012-08-20 10:43:33 -07:00
BOOST_FOREACH ( CTxDestination element , * merged )
2012-08-01 09:48:42 -07:00
setmap [ element ] = merged ;
}
2012-08-20 10:43:33 -07:00
set < set < CTxDestination > > ret ;
BOOST_FOREACH ( set < CTxDestination > * uniqueGrouping , uniqueGroupings )
2012-08-01 09:48:42 -07:00
{
ret . insert ( * uniqueGrouping ) ;
delete uniqueGrouping ;
}
return ret ;
}
2013-07-15 16:01:09 -07:00
set < CTxDestination > CWallet : : GetAccountAddresses ( string strAccount ) const
{
set < CTxDestination > result ;
BOOST_FOREACH ( const PAIRTYPE ( CTxDestination , CAddressBookData ) & item , mapAddressBook )
{
const CTxDestination & address = item . first ;
const string & strName = item . second . name ;
if ( strName = = strAccount )
result . insert ( address ) ;
}
return result ;
}
2013-04-25 10:30:28 -07:00
bool CReserveKey : : GetReservedKey ( CPubKey & pubkey )
2011-06-26 10:23:24 -07:00
{
if ( nIndex = = - 1 )
{
CKeyPool keypool ;
pwallet - > ReserveKeyFromKeyPool ( nIndex , keypool ) ;
2011-07-13 18:11:40 -07:00
if ( nIndex ! = - 1 )
vchPubKey = keypool . vchPubKey ;
2013-04-25 10:30:28 -07:00
else {
if ( pwallet - > vchDefaultKey . IsValid ( ) ) {
2013-09-18 03:38:08 -07:00
LogPrintf ( " CReserveKey::GetReservedKey(): Warning: Using default key instead of a new key, top up your keypool! " ) ;
2013-04-25 10:30:28 -07:00
vchPubKey = pwallet - > vchDefaultKey ;
} else
return false ;
2011-07-13 18:28:31 -07:00
}
2011-06-26 10:23:24 -07:00
}
2012-05-14 10:07:52 -07:00
assert ( vchPubKey . IsValid ( ) ) ;
2013-04-25 10:30:28 -07:00
pubkey = vchPubKey ;
return true ;
2011-06-26 10:23:24 -07:00
}
void CReserveKey : : KeepKey ( )
{
if ( nIndex ! = - 1 )
pwallet - > KeepKey ( nIndex ) ;
nIndex = - 1 ;
2012-05-14 10:07:52 -07:00
vchPubKey = CPubKey ( ) ;
2011-06-26 10:23:24 -07:00
}
void CReserveKey : : ReturnKey ( )
{
if ( nIndex ! = - 1 )
pwallet - > ReturnKey ( nIndex ) ;
nIndex = - 1 ;
2012-05-14 10:07:52 -07:00
vchPubKey = CPubKey ( ) ;
2011-06-26 10:23:24 -07:00
}
2011-07-07 06:22:54 -07:00
2013-04-29 10:50:40 -07:00
void CWallet : : GetAllReserveKeys ( set < CKeyID > & setAddress ) const
2011-07-11 12:49:45 -07:00
{
setAddress . clear ( ) ;
CWalletDB walletdb ( strWalletFile ) ;
2012-04-06 09:39:12 -07:00
LOCK2 ( cs_main , cs_wallet ) ;
2013-04-12 22:13:08 -07:00
BOOST_FOREACH ( const int64_t & id , setKeyPool )
2011-07-11 12:49:45 -07:00
{
CKeyPool keypool ;
if ( ! walletdb . ReadPool ( id , keypool ) )
throw runtime_error ( " GetAllReserveKeyHashes() : read failed " ) ;
2012-05-14 10:07:52 -07:00
assert ( keypool . vchPubKey . IsValid ( ) ) ;
2012-05-14 14:44:52 -07:00
CKeyID keyID = keypool . vchPubKey . GetID ( ) ;
if ( ! HaveKey ( keyID ) )
2011-07-11 12:49:45 -07:00
throw runtime_error ( " GetAllReserveKeyHashes() : unknown key in key pool " ) ;
2012-05-14 14:44:52 -07:00
setAddress . insert ( keyID ) ;
2011-07-11 12:49:45 -07:00
}
}
2012-05-05 07:07:14 -07:00
void CWallet : : UpdatedTransaction ( const uint256 & hashTx )
{
{
LOCK ( cs_wallet ) ;
// Only notify UI if this transaction is in this wallet
map < uint256 , CWalletTx > : : const_iterator mi = mapWallet . find ( hashTx ) ;
if ( mi ! = mapWallet . end ( ) )
NotifyTransactionChanged ( this , hashTx , CT_UPDATED ) ;
}
}
2012-09-27 10:52:09 -07:00
void CWallet : : LockCoin ( COutPoint & output )
{
setLockedCoins . insert ( output ) ;
}
void CWallet : : UnlockCoin ( COutPoint & output )
{
setLockedCoins . erase ( output ) ;
}
void CWallet : : UnlockAllCoins ( )
{
setLockedCoins . clear ( ) ;
}
bool CWallet : : IsLockedCoin ( uint256 hash , unsigned int n ) const
{
COutPoint outpt ( hash , n ) ;
return ( setLockedCoins . count ( outpt ) > 0 ) ;
}
void CWallet : : ListLockedCoins ( std : : vector < COutPoint > & vOutpts )
{
for ( std : : set < COutPoint > : : iterator it = setLockedCoins . begin ( ) ;
it ! = setLockedCoins . end ( ) ; it + + ) {
COutPoint outpt = ( * it ) ;
vOutpts . push_back ( outpt ) ;
}
}
2013-04-12 22:13:08 -07:00
void CWallet : : GetKeyBirthTimes ( std : : map < CKeyID , int64_t > & mapKeyBirth ) const {
2013-04-29 10:50:40 -07:00
mapKeyBirth . clear ( ) ;
// get birth times for keys with metadata
for ( std : : map < CKeyID , CKeyMetadata > : : const_iterator it = mapKeyMetadata . begin ( ) ; it ! = mapKeyMetadata . end ( ) ; it + + )
if ( it - > second . nCreateTime )
mapKeyBirth [ it - > first ] = it - > second . nCreateTime ;
// map in which we'll infer heights of other keys
2013-10-10 14:07:44 -07:00
CBlockIndex * pindexMax = chainActive [ std : : max ( 0 , chainActive . Height ( ) - 144 ) ] ; // the tip can be reorganised; use a 144-block safety margin
2013-04-29 10:50:40 -07:00
std : : map < CKeyID , CBlockIndex * > mapKeyFirstBlock ;
std : : set < CKeyID > setKeys ;
GetKeys ( setKeys ) ;
BOOST_FOREACH ( const CKeyID & keyid , setKeys ) {
if ( mapKeyBirth . count ( keyid ) = = 0 )
mapKeyFirstBlock [ keyid ] = pindexMax ;
}
setKeys . clear ( ) ;
// if there are no such keys, we're done
if ( mapKeyFirstBlock . empty ( ) )
return ;
// find first block that affects those keys, if there are any left
std : : vector < CKeyID > vAffected ;
for ( std : : map < uint256 , CWalletTx > : : const_iterator it = mapWallet . begin ( ) ; it ! = mapWallet . end ( ) ; it + + ) {
// iterate over all wallet transactions...
const CWalletTx & wtx = ( * it ) . second ;
std : : map < uint256 , CBlockIndex * > : : const_iterator blit = mapBlockIndex . find ( wtx . hashBlock ) ;
2013-10-10 14:07:44 -07:00
if ( blit ! = mapBlockIndex . end ( ) & & chainActive . Contains ( blit - > second ) ) {
2013-04-29 10:50:40 -07:00
// ... which are already in a block
int nHeight = blit - > second - > nHeight ;
BOOST_FOREACH ( const CTxOut & txout , wtx . vout ) {
// iterate over all their outputs
: : ExtractAffectedKeys ( * this , txout . scriptPubKey , vAffected ) ;
BOOST_FOREACH ( const CKeyID & keyid , vAffected ) {
// ... and all their affected keys
std : : map < CKeyID , CBlockIndex * > : : iterator rit = mapKeyFirstBlock . find ( keyid ) ;
if ( rit ! = mapKeyFirstBlock . end ( ) & & nHeight < rit - > second - > nHeight )
rit - > second = blit - > second ;
}
vAffected . clear ( ) ;
}
}
}
// Extract block timestamps for those keys
for ( std : : map < CKeyID , CBlockIndex * > : : const_iterator it = mapKeyFirstBlock . begin ( ) ; it ! = mapKeyFirstBlock . end ( ) ; it + + )
mapKeyBirth [ it - > first ] = it - > second - > nTime - 7200 ; // block times can be 2h off
}