Author

Topic: [PULL] Modularizing bitcoin: CWallet class (Read 1491 times)

legendary
Activity: 1072
Merit: 1174
June 01, 2011, 05:28:34 PM
#2
Pull request is up: https://github.com/bitcoin/bitcoin/pull/288

It seems stable now, i've received and sent (realnet) transactions with it without problems. Feel free to test Smiley
legendary
Activity: 1072
Merit: 1174
Hello all,

I've been working on restructuring the bitcoin source code a bit. A first step was splitting off all wallet-handling into a separate class CWallet, so that eventually eg. multiple loaded wallets at the same time are possible, less global variables are needed and in general the dependencies inside the code are improved.

I ended up changing somewhat more than expected, as really a lot of code depended on access to those globals.

A summary:
  • A new class CKeyStore manages private keys, and script.cpp depends on access to CKeyStore.
  • A new class CWallet extends CKeyStore, and contains all former wallet-specific globals; CWallet depends on script.cpp, not the other way around.
  • Wallet-specific functions in CTransaction (GetDebit, GetCredit, GetChange, IsMine, IsFromMe), are moved to CWallet, taking their former 'this' argument as an explicit parameter
  • CWalletTx objects know which CWallet they belong to, for convenience, so they have their own direct (and caching) GetDebit/... functions.
  • Some code was moved between CWalletDB, CWallet and main.
  • Main.cpp keeps a set of all 'registered' wallets, which should be informed about updates to the block chain, and does not have any notion about any 'main' wallet. Function in main.cpp that require a wallet (such as GenerateCoins), take an explicit CWallet* argument.
  • The actual CWallet instance used by the application is defined in init.cpp as "CWallet* pwalletMain". rpc.cpp and ui.cpp use this variable.

The code is here: https://github.com/sipa/bitcoin/tree/walletclass/src

Note that the branch is not yet rebased against the current master, is a work in progress and may have bugs. There should not be any changes to the actual program logic, but segfaults or performance degradations are definitely possible.

Comments are welcome.
Jump to: