Basic multiwallet support #8694

luke-jr · Sep 9, 2016

This allows running with multiple -wallet options to load more than one wallet.

GUI has independent comboboxen for the main GUI window and debug console to select which wallet to view/use. The comboboxes are not visible in the main GUI unless multiple wallets are loaded (the debug window's combobox is useful even for a single wallet, since it allows selecting "(none)" to block wallet access).

RPC can access only one wallet per user, but rpcauth is extended to accept a 4th field which controls which wallet, if any, the user has access to. I chose to do it this way because pre-multiwallet nodes will gracefully ignore such rpcauth rather than expose their wallet. The field can also be a single hyphen to block wallet access.

(RPC and GUI changes are moved to my multiwallet_rpc and multiwallet_gui branches)

jonasschnelli · Sep 10, 2016

Impressive changeset!
General Concept ACK.

Instead of the extending the RPC auth, I could imaging using different RPC endpoints would also work.

Accessing RPC at / would result in the default wallet.
Accessing RPC at /<walletid> would result in using the wallet with the id <walletid>.

bitcoin-cli could just support a new argument -walletid.
Something like bitcoin-cli -walletid=something getbalance would result in the same RPC call just against the endpoint /something.
Maybe this would result in a simple RPC access to the multiple wallets.

Will review soon.

luke-jr · Sep 10, 2016

Instead of the extending the RPC auth, I could imaging using different RPC endpoints would also work.

Indeed, although my main purpose in doing this was to isolate JoinMarket, and it's less isolated if it has auth to my real hotwallet. :)

(Also, endpoints seemed like they'd require more code.)

Accessing RPC at /<walletid> would result in using the wallet with the id <walletid>.

This isn't very future-proof. If we go this route, I'd suggest /?wallet=<walletid>

btcdrak · Sep 14, 2016

Nice, Concept ACK. Will test.

MarcoFalke · Sep 21, 2016

MarcoFalke reviewed Sep 21, 2016

View changes

I like the approach by @jonasschnelli better. Let's keep most of the multiwallet logic in wallet.cpp.

It's not in wallet.cpp now. Moving it there seems like a good idea, but independent of this PR...

luke-jr · Jan 3, 2017

Rebased, but please prioritise #8775 review (which this is based on) first. Once that's merged, it may or may not make sense to split the Qt changes out of this.

gmaxwell · Jan 7, 2017

Concept ACK.

Syntax for the auth field should have a clear way to extend it to support a list of wallets (first being the default, I guess). I think. To support things like the path selected wallets suggested above later.

luke-jr · Feb 3, 2017

Moved RPC/GUI changes out of this, and rebased.

luke-jr · Mar 4, 2017

Rebased and now the next-step in multiwallet integration.

jonasschnelli · Mar 6, 2017

Re-Concept ACK.
Binaries to play with: https://bitcoin.jonasschnelli.ch/build/PR/8694

ryanofsky · Mar 6, 2017

ryanofsky reviewed Mar 6, 2017

View changes

Curious, why have a CWallet_ptr typedef instead of using CWallet *? Is there a plan to switch to a different type of pointer later? Curious, because this seems to make the rest of the code more opaque. For example:

for (CWallet_ptr pwallet : vpwallets)

Because this says CWallet_ptr instead of CWallet* it's unclear whether the copy initialization has extra cost (which it would for a shared_ptr), implying a const reference should be used instead.

Indeed, a shared_ptr or similar would be needed for when/if we add the ability to close wallets at runtime.

This thread is created from the non-static method CWallet::postInitProcess, so it seems like it makes more sense for it to continue flushing a single wallet, rather than going through the global wallets list. Instead of looping and accessing the global vpwallet variable, ThreadFlushWalletDB could just take a new CWallet* pwallet argument and be invoked with:

threadGroup.create_thread([this](){ThreadFlushWalletDB(this);});

from CWallet::postInitProcess.

Having a dedicated thread per wallet is just needlessly inefficient.

How come the nLastFlushed assignment is moving ouside of the _mi != bitdb.mapFileUseCount.end() condition? It seems unrelated to this change. Maybe a code comment explaining the assignment would be good here.

Because the condition is per-wallet. Maybe nLastFlushed ought to be as well...?

Sanitised this better in the rebase

ryanofsky · Mar 8, 2017

(needs another rebase)

laanwj · Mar 9, 2017

Added 0.15.0 milestone.

luke-jr · Mar 9, 2017

Significantly rebased. Also fixed minor race conditions surrounding wallet flush (it was bumping the "have update to flush" counter before doing the actual update).

laanwj · Mar 10, 2017

It would be preferable to increment the update counter after committing a database transaction, not after every call to a CWalletDB method.
So this would mean the destructor of CWalletDB and TxnCommit() . Which should be overridden in CWalletDB, or alternatively use composition not inheritance for CDB as I've done in the last commit in #9951.
This will simplify these changes (no need to do WriteIC/EraseIC everywhere), as well as makes sure that only changes that actually hit the database/disk are counted.

laanwj · Mar 10, 2017

laanwj reviewed Mar 10, 2017

View changes

I think it is confusing for a "Set" function to add something to a list. If anything it should replace it.
What do you need this for, specifically?
In the past I've defined SoftSetMultiArg to be able to define a whole list argument at once.

It can't get here unless the list is currently empty. It's used to initialise -wallet, which is accessed as a list only now.

I believe this is also not correct - other threads may be using mapMultiArgs or the vector in it at the same time

Maybe get @jtimon to do it in #9494 and then just use it here?

It can't get here unless the list is currently empty.

Good point

@TheBlueMatt I don't see what your concern is... We have the lock here already.

We do not take the lock when accessing mapMultiArgs all over the codebase. You cannot write a new entry to this map without updating the various locations in the codebase which access mapMultiArgs to also go through cs_args.

laanwj · Mar 10, 2017

laanwj reviewed Mar 10, 2017

View changes

Why define pwalletMain here?

There's no need to modify the tests to use vpwallets in most cases?

In commit "Wallet: Replace pwalletMain with a vector of wallet pointers":

Maybe add a TODO comment for updating the tests to stop referencing pwalletMain, since this will be confusing to someone seeing this who isn't familiar with the pre-multiwallet history of the code.

Depends on the reason why they are setting pwalletMain. Generally that is to communicate with stuff in wallet.cpp/walletdb.cpp I'd say.

laanwj · Mar 10, 2017

I think the overall approach here is good. This is another step towards multi-wallet support. As it's not anywhere on the API yet, I guess it's too early to ask for a multiwallet test?

luke-jr · Mar 10, 2017

It would be preferable to increment the update counter after committing a database transaction, not after every call to a CWalletDB method.

IMO too much for this PR. Just trying to multiwallet here, not refactor stuff that doesn't need it. :)

laanwj · Mar 10, 2017

IMO too much for this PR. Just trying to multiwallet here, not refactor stuff that doesn't need it. :)

Maybe my recommendation goes to far but I just think your current approach there is messy. The mutator functions call WriteIC/EraseIC which call IncrementUpdateCounter which calls IncrementUpdateCounter(strFile) which indexes into a global map indexed by name. This makes the wallet code even more complex and hard to understand as it introduces another place where per-wallet(-database) information is stored.

We need to decide whether CWalletDBStateInfo belongs with the database wrapper, or with the wallet.

If it is part of the database statistics side of things, the place to put it would be CDBEnv, with the other maps mapFileUseCount and mapDb. After #9951 I'm going to refactor these to put them on a CDBWrapper object which represents a single database.
If it is specific to wallets, the structure could be put on CWallet, and a reference passed in where it is needed (e.g. to CWalletDB) instead of looking it up all the time. This makes the CWallet more self-contained.

ryanofsky · Mar 10, 2017

ryanofsky reviewed Mar 10, 2017

View changes

utACK 3f096ca

In commit "Wallet: Replace pwalletMain with a vector of wallet pointers":

Maybe add a TODO comment for updating the tests to stop referencing pwalletMain, since this will be confusing to someone seeing this who isn't familiar with the pre-multiwallet history of the code.

In commit "Bugfix: wallet: Increment "update counter" only after actually making the applicable db changes to avoid potential races":

It seems good not to increment the counter when a write or erase fails. But I don't understand what the "potential races" are that could happen if the counter is incremented regardless. If you could clarify / expand the commit message on this point, I think that would be helpful.

(thread 1) Increment the counter.
(thread 2) DB gets flushed
(thread 1) Actual change happens.
(thread 2) Thinks DB hasn't changed, so doesn't flush again.

In commit "Bugfix: wallet: Increment "update counter" only after actually making the applicable db changes to avoid potential races":

I'm probably missing something, but if the first write above succeeds and second write fails, the counter won't be incremented. Is this wrong? Would a possible fix be to drop this line and replace all the Write/Erases above with WriteIC/EraseIC?

Hmm, not sure what we want to happen in that case...

This is one of the reasons why I suggested above to only update the update counter if a DB transaction actually hits the database. That's more robust than doing it per operation. It's possible for all the operations to succeed then TxnAbort() to be called and still no update happens.

I agree, but it's outside the scope of this PR. For now, I'll just increment the counter more aggressively (merely reordering the increment to fix the race issue).

luke-jr · Mar 11, 2017

@laanwj I agree that stuff should be refactored, but I don't think multiwallet needs to depend on it here.

(Why is CWalletDB not just a private parent class of CWallet anyway?)

laanwj · Mar 11, 2017

(Why is CWalletDB not just a private parent class of CWallet anyway?)

It's named wrongly. Because CWalletDB is not a database, it provides access to it. To be exact, it is a database transaction, similar to the CDBBatch in leveldbwrapper.h. It is commited when the object goes out of scope or TxnCommit() is called. It is not committed if TxnAbort() is called.
Should at least use composition there not inheritance. A wallet uses a wallet database, it is not a wallet database. This avoids low-level implementation details from leaking through.

I agree that stuff should be refactored, but I don't think multiwallet needs to depend on it here.

As said I understand that. I'm not asking for you to do big changes. I just don't want it to become even worse and more muddled.

I might pick this up myself if I have some time next week.

TheBlueMatt · Mar 21, 2017

TheBlueMatt reviewed Mar 21, 2017

View changes

Barely got started, will finish review later.

Don't you still need to delete each wallet here?

I believe this is also not correct - other threads may be using mapMultiArgs or the vector in it at the same time

Why typedef this? Its literally /more/ characters now.

Typedef-ing a pointer type doesn't seem that useful to me either. I suppose the rationale is "what if we want to change it to e.g. std::shared_ptr later". But a) I think the code is more readable if the kind of pointer is clear from the function/struct/class signatures using it b) You might want to have different kinds of pointers to the same kind of objects in different places.

not sure it make sense either, but if it is done, better naming it to CWalletRef to be consistent with CTransactionRef

NicolasDorier · Apr 12, 2017

NicolasDorier reviewed Apr 12, 2017

View changes

I throwing an RPC error like RPC_METHOD_NOT_FOUND is better than returning NULL.

It is not always an error for there to be no wallet (eg, signrawtransaction).

NicolasDorier · Apr 12, 2017

NicolasDorier reviewed Apr 12, 2017

View changes

vpwallets.clear() ?

EDIT: Meh, not really needed, just thought it would be more coherent.

NicolasDorier · Apr 12, 2017

not blocking, but I think a CWallets instead of vpwallets it would make the code way easier to read and less error prone.
Would also make locking easier to get right, and preventing some loop.

It would impact:

std::map<std::string, CWalletDBStateInfo> WalletDBStateInfos
std::vector<CWallet_ptr> vpwallets;
IncrementUpdateCounter()

That said, this can be done in a separate PR.

laanwj · Apr 12, 2017

laanwj reviewed Apr 12, 2017

View changes

s/NULL/nullptr?

laanwj · Apr 12, 2017

laanwj reviewed Apr 12, 2017

View changes

walletFile.find_first_of("/\\") is not portable. Likely, boost::filesystem::path has a way to check a path for path separators.

        boost::filesystem::path walletFileBoost = walletFile;
        if (walletFileBoost.has_root_path() || walletFileBoost.has_parent_path()) {

This would work, but off-topic here since this is existing code.

luke-jr · Apr 18, 2017

In-scope nits addressed and rebased.

jtimon · Apr 18, 2017

jtimon reviewed Apr 18, 2017

View changes

why clear here? afaik this is only used for unittests now.

So that there's only one value in _mapMultiArgs...

luke-jr · May 21, 2017

Rebased

ryanofsky · May 22, 2017

ryanofsky reviewed May 22, 2017

View changes

utACK 68bc5b9. This is much simpler than before and the bugfixes and cleanup are nice even independent of the multiwallet changes.

In commit "Wallet: Replace pwalletMain with a vector of wallet pointers"

Should initialize these values.

Should initialize these values.

Note: comment no longer applies. This is now done in two CWalletDBWrapper constructors.

In commit "Wallet: Replace pwalletMain with a vector of wallet pointers"

It would be nice if conversion of these values from static variables to per-wallet members happened in the previous commit ("CWalletDB: Store the update counter per wallet") instead of this one. Would make both commits easier to follow and avoid the unusual intermediate state where globals and per-wallet members are compared to each other.

In commit "CWalletDB: Store the update counter per wallet":

Should initialize this value.

It's an atomic, should have a default constructor?

It's an atomic, should have a default constructor?

Yes but it seems to not initialize the value, see
https://stackoverflow.com/questions/36320008/whats-the-default-value-for-a-stdatomic or http://en.cppreference.com/w/cpp/atomic/atomic/atomic. IMO, adding = 0 to this line would make the code clearer anyway.

In commit "CWalletDB: Store the update counter per wallet"

Maybe call this dbw for consistency with existing wallet code.

In commit "Bugfix: wallet: Increment "update counter" only after actually making the applicable db changes to avoid potential races"

Would be helpful to have a comment mentioning that counter should be updated after the write operation, rather than before to prevent a race where the flush thread could run and store the higher counter value before the database is fully updated.

Could also mention the idea of moving the counter increment to the destructor / commit function so these write and erase wrappers would be unnecessary.

In commit "CWalletDB: Store the update counter per wallet"

Might be nice to call this member dbw instead of wrapper for consistency with the wallet member.

jonasschnelli · May 24, 2017

jonasschnelli reviewed May 24, 2017

View changes

This redundantly opens/checks the datadir via BDB. Not sure if this is a problem...

jonasschnelli · May 24, 2017

jonasschnelli reviewed May 24, 2017

View changes

Without a lock we set the assumption that vpwallets is immutable.

jonasschnelli · May 24, 2017

jonasschnelli reviewed May 24, 2017

View changes

nit: using Verifying wallet(s)...?

jonasschnelli · May 24, 2017

jonasschnelli reviewed May 24, 2017

View changes

This renames an arbitrary wallet name to "wallet.%d.bak", collisions may happen.

2017-05-24 07:56:04 Renamed test1.dat to wallet.1495612559.bak

Maybe we should use <filename>.<date>.bak (will result in something like test1.dat.1495612559.bak (which is preferable IMO).

I agree with @jonasschnelli . This seems dangerous if Recover() or VerifyDatabaseFile() is called for multiple wallets. Should be straightforward to update Recover() to name the backup file uniquely (the warning string in VerifyDatabaseFile() will also need to be updated)

jonasschnelli · May 24, 2017

Tested a bit and seems to work as intended.
The only point I found during testing that needs fixing is the SalvageWallet renaming to "wallet.%d.bak".
Step-debugged the flushing and SyncTransaction.

Conceptual:

This PR mostly goes into a direction that one has to choose the wallets-to-work-with before starting up Core. I miss the pre-work for run-time adding and removing of wallets. Sure, this may be added later.
Furthermore, the "globalness" of the startup arguments and action like -usehd or -zapwallettxes, --keypool, etc. are somehow conceptual issues that need to be solved before deploying multiwallet.

Ideally creating, loading and unloading of wallets happens during runtime over an RPC call (or though the GUI).
In the long run, actions like zapwallettx, salvagewallet, rescan, upgradewallet, etc should also be moved to runtime.
Per wallet settings like -usehd, -keypool, etc. should be values that can be set during creation (or loading of a wallet).

jonasschnelli · May 24, 2017

Gitian builds are failing (all three platforms): https://bitcoin.jonasschnelli.ch/build/147

gmaxwell · May 25, 2017

zapwallettx, salvagewallet

These should probably become less visible or go away or move to a separate utility.

rescan

We can do this from the rpc now.

Not sure about upgradewallet.

jnewbery · May 29, 2017

jnewbery reviewed May 29, 2017

View changes

A couple of small nits inline, and a couple of general comments:

I think this could do with both unit and integration tests
Please update the comment for CWallet::Verify() in wallet.h now that it's responsible for parsing the wallet arguments and populating the ArgsManager

You've changed MaybeCompactWalletDB() to access CDB::nUpdateCounter directly, so this function isn't used.

I agree with @jonasschnelli . This seems dangerous if Recover() or VerifyDatabaseFile() is called for multiple wallets. Should be straightforward to update Recover() to name the backup file uniquely (the warning string in VerifyDatabaseFile() will also need to be updated)

Please update to use braces. You can also combine this line with the one below.

Several other if statements below which you can update to use braces.

luke-jr · Jun 5, 2017

Rebased and issues addressed

laanwj · Jun 6, 2017

Travis falure:

Running 255 test cases...
unknown location(0): fatal error: in "wallet_tests/importwallet_rescan": unknown type
wallet/test/wallet_tests.cpp(446): last checkpoint: "importwallet_rescan" entry.
*** 1 failure is detected in the test module "Bitcoin Test Suite"

ryanofsky · Jun 6, 2017

Travis falure:

The importwallet_rescan test has another pwalletMain usage that needs to be changed to vpwallets.

ryanofsky · Jun 6, 2017

ryanofsky reviewed Jun 6, 2017

View changes

utACK 33f0b60 with the test fix. First 6 commits were basically unchanged since my previous review (just a member rename and atomic init fixes). 7 new commits have been added and seem fine.

In commit "Wallet: Support loading multiple wallets if -wallet used more than once"

Removing GetUpdateCounter in this commit isn't related to the rest of the changes here. This change was probably meant for the "CWalletDB: Store the update counter per wallet" commit.

Should initialize these values.

Note: comment no longer applies. This is now done in two CWalletDBWrapper constructors.

In commit "Replace pwalletMain with a vector of wallet"

This can probably be removed after the importwallet_rescan test is updated.

This can probably be removed after the importwallet_rescan test is updated.

Never mind, it's used by the receiverequests test.

In commit "Wallet: Move multiwallet sanity checks to CWallet::Verify"

Consider squashing this commit into previous commit "Wallet: Support loading multiple wallets if -wallet used more than once", because the two commits are making parallel sets changes, and having them separate makes the interaction confusing to think about.

In commit "Bugfix: wallet: Fix warningStr, errorStr argument order"

Note: the bug seems to have been introduced in #8574.

jnewbery · Jun 6, 2017

I've had a quick scan and the new commits look generally good, although #10457 seems like a simpler solution to the wallet backup name issue. I don't think it's really worth passing the backup file name around through multiple function calls just so it can be printed in a single warning message.

I'll fully review once the the test has been fixed.

achow101 · Jun 7, 2017

achow101 reviewed Jun 7, 2017

View changes

Here you say that -salvagewallet is only for one wallet file, but in CWallet::Verify(), the loop through all wallets checks for -salvagewallet and recovers all wallets if -salvagewallet is set. Which behavior is correct: salvage all wallets, or salvage only if there is one wallet?

For the latter, the -salvagewallet check in CWallet::Verify() can be moved out of the loop.

Both are correct. If we get to ::Verify, we should salvage all wallets. But for now, we forbid this combination. Moving it out of the loop is error-prone, and creates unnecessary complexity.

ryanofsky · Jun 9, 2017

ryanofsky reviewed Jun 9, 2017

View changes

utACK c237bd7. Changes since previous review were fixing rescan test, updating a salvagewallet comment, and removing GetUpdateCounter in an earlier commit.

This can probably be removed after the importwallet_rescan test is updated.

Never mind, it's used by the receiverequests test.

laanwj · Jun 12, 2017

utACK c237bd7
Seems ready to merge.

laanwj · Jun 12, 2017

I've had a quick scan and the new commits look generally good, although #10457 seems like a simpler solution to the wallet backup name issue. I don't think it's really worth passing the backup file name around through multiple function calls just so it can be printed in a single warning message.

I agree. We should probably revert that part and do #10457 afterward.

MarcoFalke added the Wallet label Sep 9, 2016

This was referenced Sep 10, 2016

Closed

Using multiple wallet files with bitcoind #3113

Open

Qt GUI Feature Request: Load wallet file #7675

jonasschnelli referenced this pull request Sep 20, 2016
Closed
[Wallet] get rid of pwalletMain, add simple CWallets infrastructure #8764

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

Wallet: Replace pwalletMain with a vector of wallet pointers
Github-Pull: #8694 Rebased-From: 17480ed9dbd535b174342d02e4a3627ff9ddc193

d6ebde7

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

Wallet: Support loading multiple wallets if -wallet used more than once
Github-Pull: #8694 Rebased-From: 03b8a1380e2c91794c5ed4aac0ec50aa85405959

ca93ab2

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

Qt: Load all wallets into WalletModels
Github-Pull: #8694 Rebased-From: 4d44a06ee74240a1616b6561767901f3d5e4ad91

aaf1507

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

Qt: Add a combobox to toolbar to select from multiple wallets
Github-Pull: #8694 Rebased-From: 6f3f87fe0fcb10929a9a4f367e72767a7b49aa98

b0a256d

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

RPC: Allow rpcauth configs to specify a 4th parameter naming a specif…
…ic wallet Github-Pull: #8694 Rebased-From: df3b6d0

1f62f13

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

Qt: Add wallet selector to debug console
Github-Pull: #8694 Rebased-From: 996948a

35fcc1a

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 31, 2016

Qt: QComboBox::setVisible doesn't work in toolbars, so defer adding i…
…t at all until needed Github-Pull: #8694 Rebased-From: d8da183

9f8717c

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

Wallet: Replace pwalletMain with a vector of wallet pointers
Github-Pull: #8694 Rebased-From: 0d348d5

6e2d7c1

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

Keep mapMultiArgs consistent when *SetArg is used
Github-Pull: #8694 Rebased-From: 063cc18

d4718eb

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

Wallet: Support loading multiple wallets if -wallet used more than once
Github-Pull: #8694 Rebased-From: 2147835

b4ee0aa

laanwj self-assigned this Mar 9, 2017

laanwj added this to the 0.15.0 milestone Mar 9, 2017

laanwj added this to Blockers in High-priority for review Mar 24, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

Bugfix: wallet: Increment "update counter" when modifying account stuff
Github-Pull: #8694 Rebased-From: dbc7e79 Github-Pull: #8694 Rebased-From: 792d0f3a9fafd0f3ab9ff419f86bbbb7a30d511c

02254ca

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

wallet: Move nAccountingEntryNumber from static/global to CWallet
Github-Pull: #8694 Rebased-From: 6ef7bd9 Github-Pull: #8694 Rebased-From: fadb7d152285f79b0b398e1317c6574eff56de87

9a76eaf

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

Wallet: Move multiwallet sanity checks to CWallet::Verify, and do oth…
…er checks on all wallets Github-Pull: #8694 Rebased-From: 06b431c

cc7c34e

sipa removed this from Blockers in High-priority for review May 4, 2017

jonasschnelli referenced this pull request May 26, 2017
Closed
Don't use fixed "wallet.bak"-filename during salvagewallet #10457

laanwj merged commit c237bd7 into bitcoin:master Jun 12, 2017
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

fanquake moved this from In progress to Done in Multiwallet support Jun 12, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

wallet: Include actual backup filename in recovery warning message
Github-Pull: #8694 Rebased-From: b823a4c

d9d0870

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

wallet: Base backup filenames on original wallet filename
Github-Pull: #8694 Rebased-From: a2a5f3f

e2e2882

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

wallet: Forbid -salvagewallet, -zapwallettxes, and -upgradewallet wit…
…h multiple wallets Github-Pull: #8694 Rebased-From: 9cbe8c8

9ac761f

jnewbery referenced this pull request Jun 15, 2017
Merged
[wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test #10604

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

Bugfix: wallet_tests: Declare pwalletMain
Github-Pull: #8694 Rebased-From: b124cf0

06098ce

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

Wallet/test: Adapt importwallet_rescan test to multiwallet
Github-Pull: #8694 Rebased-From: b124cf0

c296fb4

@@ -196,8 +196,9 @@ void Shutdown()
              StopRPC();
              StopHTTPServer();
          #ifdef ENABLE_WALLET
-        -    if (pwalletMain)
-        -        pwalletMain->Flush(false);
+        +    for (CWallet_ptr pwallet : vpwallets) {

@@ -31,7 +31,8 @@
          #include <boost/shared_ptr.hpp>
          #include <boost/thread.hpp>
-        -extern CWallet* pwalletMain;
+        +typedef CWallet* CWallet_ptr;

@@ -418,6 +418,7 @@ bool SoftSetArg(const std::string& strArg, const std::string& strValue)
              if (mapArgs.count(strArg))
                  return false;
              mapArgs[strArg] = strValue;
+        +    _mapMultiArgs[strArg].push_back(strValue);

@@ -8,6 +8,8 @@
          #include "wallet/db.h"
          #include "wallet/wallet.h"
+        +CWallet *pwalletMain;

@@ -8,6 +8,8 @@
          #include "wallet/db.h"
          #include "wallet/wallet.h"
+        +CWallet *pwalletMain;

		}
		+ nLastFlushed = CWalletDB::GetUpdateCounter();

bitcoin/bitcoin

Join GitHub today

Basic multiwallet support #8694

Conversation

luke-jr commented Sep 9, 2016 • edited Edited 1 time luke-jr Sep 9, 2016

MarcoFalke added the Wallet label Sep 9, 2016

This was referenced Sep 10, 2016

jonasschnelli commented Sep 10, 2016

luke-jr commented Sep 10, 2016

btcdrak commented Sep 14, 2016

jonasschnelli referenced this pull request Sep 20, 2016

MarcoFalke reviewed Sep 21, 2016 View changes

This was referenced Sep 21, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Oct 20, 2016

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 31, 2016

luke-jr commented Jan 3, 2017

gmaxwell commented Jan 7, 2017 • edited Edited 1 time gmaxwell Jan 7, 2017

luke-jr commented Feb 3, 2017

luke-jr commented Mar 4, 2017

jonasschnelli commented Mar 6, 2017 • edited Edited 1 time jonasschnelli Mar 6, 2017

ryanofsky reviewed Mar 6, 2017 View changes

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 7, 2017

ryanofsky commented Mar 8, 2017

laanwj self-assigned this Mar 9, 2017

laanwj added this to the 0.15.0 milestone Mar 9, 2017

laanwj commented Mar 9, 2017

luke-jr commented Mar 9, 2017

laanwj commented Mar 10, 2017 • edited Edited 1 time laanwj Mar 10, 2017

laanwj reviewed Mar 10, 2017 View changes

laanwj reviewed Mar 10, 2017 View changes

laanwj commented Mar 10, 2017

luke-jr commented Mar 10, 2017

laanwj commented Mar 10, 2017

ryanofsky reviewed Mar 10, 2017 View changes

luke-jr commented Mar 11, 2017

laanwj commented Mar 11, 2017 • edited Edited 1 time laanwj Mar 11, 2017

TheBlueMatt reviewed Mar 21, 2017 View changes

laanwj added this to Blockers in High-priority for review Mar 24, 2017

NicolasDorier reviewed Apr 12, 2017 View changes

NicolasDorier Apr 12, 2017 • edited Edited 1 time NicolasDorier Apr 12, 2017

NicolasDorier reviewed Apr 12, 2017 View changes

NicolasDorier Apr 12, 2017 • edited Edited 1 time NicolasDorier Apr 12, 2017

NicolasDorier commented Apr 12, 2017

laanwj reviewed Apr 12, 2017 View changes

laanwj reviewed Apr 12, 2017 View changes

luke-jr commented Apr 18, 2017

jtimon reviewed Apr 18, 2017 View changes

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Apr 21, 2017

sipa removed this from Blockers in High-priority for review May 4, 2017

luke-jr commented May 21, 2017

ryanofsky reviewed May 22, 2017 View changes

jonasschnelli reviewed May 24, 2017 View changes

jonasschnelli reviewed May 24, 2017 View changes

jonasschnelli reviewed May 24, 2017 View changes

jonasschnelli reviewed May 24, 2017 View changes

jonasschnelli commented May 24, 2017

Conceptual:

jonasschnelli commented May 24, 2017

gmaxwell commented May 25, 2017

jonasschnelli referenced this pull request May 26, 2017

jnewbery reviewed May 29, 2017 View changes

luke-jr added some commits Jan 3, 2017

luke-jr commented Jun 5, 2017

laanwj commented Jun 6, 2017

ryanofsky commented Jun 6, 2017

ryanofsky reviewed Jun 6, 2017 View changes

jnewbery commented Jun 6, 2017

luke-jr added some commits Sep 9, 2016

achow101 reviewed Jun 7, 2017 View changes

luke-jr commented Sep 9, 2016 •

Edited 1 time

luke-jr
Sep 9, 2016

MarcoFalke reviewed Sep 21, 2016

View changes

gmaxwell commented Jan 7, 2017 •

Edited 1 time

gmaxwell
Jan 7, 2017

jonasschnelli commented Mar 6, 2017 •

Edited 1 time

jonasschnelli
Mar 6, 2017

ryanofsky reviewed Mar 6, 2017

View changes

laanwj commented Mar 10, 2017 •

Edited 1 time

laanwj
Mar 10, 2017

laanwj reviewed Mar 10, 2017

View changes

laanwj reviewed Mar 10, 2017

View changes

ryanofsky reviewed Mar 10, 2017

View changes

laanwj commented Mar 11, 2017 •

Edited 1 time

laanwj
Mar 11, 2017

TheBlueMatt reviewed Mar 21, 2017

View changes

NicolasDorier reviewed Apr 12, 2017

View changes

NicolasDorier Apr 12, 2017 •

Edited 1 time

NicolasDorier
Apr 12, 2017

NicolasDorier reviewed Apr 12, 2017

View changes

NicolasDorier Apr 12, 2017 •

Edited 1 time

NicolasDorier
Apr 12, 2017

laanwj reviewed Apr 12, 2017

View changes

laanwj reviewed Apr 12, 2017

View changes

jtimon reviewed Apr 18, 2017

View changes

ryanofsky reviewed May 22, 2017

View changes

jonasschnelli reviewed May 24, 2017

View changes

jonasschnelli reviewed May 24, 2017

View changes

jonasschnelli reviewed May 24, 2017

View changes

jonasschnelli reviewed May 24, 2017

View changes

jnewbery reviewed May 29, 2017

View changes

ryanofsky reviewed Jun 6, 2017

View changes

achow101 reviewed Jun 7, 2017

View changes