Add HD wallet auto-restore functionality #10240

jonasschnelli · 2017-04-20T15:30:35Z

This PR ensures that we always check the keypool during SyncTransaction and, that the lookup window for HD restore is large enough (currently +20 keys).
Once the keypool size falls below the min gap limit (currently 20 keys) and the keypool can't be extended (locked wallet), the wallet then temporary pauses synchronisation.

unencrypted wallets

For unencrypted wallets, the key pool will always be topped up. During sync (SyncTransaction), we check for used keypool keys and mark all keys up to the matched key as used. Additionally we topup the keypool to ensure we not fall below the gap limit (20 keys).

encrypted wallets in non pruning mode

Same as above, but, If we hit the gap limit with an encrypted wallet, we can't topup the keypool. In that case, we just pause the sync (not the node, only the wallet).
Once the user unlocks the wallet over walletpassphrase, we rescan down to the point where we have stopped previously to ensure we don't miss possible funds.

encrypted wallets in pruned mode

Same as above, but, we also stop requesting and connecting blocks. The full node will "pause" in this case until the user did unlock his wallet (== topup, rescan, etc.).

This has a little bit of complexity and requires careful reviews.

ryanofsky · 2017-05-01T18:46:02Z

I know there was discussion about this in IRC last week, but I didn't follow closely. Would it be better to review this PR now, or hold off for more changes?

jonasschnelli · 2017-05-02T13:08:00Z

I'm currently implementing the changes we discussed in last weeks RIC meeting. A review makes more sense after the overhaul.

jonasschnelli · 2017-05-03T15:37:31Z

Completely rewrote this PR. Keeping the WIP tag for now.
The current implementation takes care of encrypted and unencrypted wallets (also in conjunction with pruning).

unencrypted wallets

For unencrypted wallets, the key pool will always be topped up. During sync (SyncTransaction), we check for used keypool keys and mark all keys up to the matched key as used. Additionally we topup the keypool to ensure we not fall below the gap limit (20 keys).

encrypted wallets in non pruning mode

Same as above, but, If we hit the gap limit with an encrypted wallet, we can't topup the keypool. In that case, we just pause the sync (not the node, only the wallet).
Once the user unlocks the wallet over walletpassphrase, we rescan down to the point where we have stopped previously to ensure we don't miss possible funds.

encrypted wallets in pruned mode

Same as above, but, we also stop requesting and connecting blocks. The full node will "pause" in this case until the user did unlock his wallet (== topup, rescan, etc.).

This has a little bit of complexity and requires careful reviews.
Thanks for early feedback.

jonasschnelli · 2017-05-04T15:48:50Z

All tests are passing now.
Removed WIP tag.
Overhauled PR description

jonasschnelli · 2017-05-04T15:53:27Z

src/wallet/wallet.cpp

        {
+            // check if we need to flag used keypool keys
+            std::set<CKeyID> setKeyPool;
+            GetAllReserveKeys(setKeyPool);


I guess this is very inefficient and something like #10235 should allow to speed up things.

ryanofsky · 2017-05-05T16:03:34Z

src/wallet/wallet.cpp

In commit "Add basic HD wallet restore functionality"

Maybe rename this variable. (It shadows CWallet::setKeyPool, which makes that variable more annoying to grep for.)

Maybe rename this variable. (It shadows CWallet::setKeyPool, which makes that variable more annoying to grep for.)

Done in 2a203b7

ryanofsky · 2017-05-05T16:32:30Z

src/wallet/wallet.cpp

In commit "Add basic HD wallet restore functionality"

Maybe avoid BOOST_FOREACH here and below.

Maybe avoid BOOST_FOREACH here and below.

Done in 2a203b7

ryanofsky · 2017-05-05T16:59:29Z

src/wallet/wallet.cpp

+        if (!walletdb.ReadPool(id, keypool))
+            throw std::runtime_error(std::string(__func__) + ": read failed");
+
+        if (keypool.vchPubKey.GetID() == keyId) {


In commit "Add basic HD wallet restore functionality"

It seems like this for-loop could be eliminated if you just changed GetAllReserveKeys to return map<CKeyID, int64_t> instead of set<CKeyID>. I think making this change would add less code than is written here.

It would also require to keep the fInternal flags in memory (for the address book internal/external change flagging). This is independently addresses in #10238.

It would also require to keep the fInternal flags in memory (for the address book internal/external change flagging). This is independently addresses in #10238.

Yeah probably not worth simplifying this if it will be obsoleted by #10238.

ryanofsky · 2017-05-05T17:01:52Z

src/wallet/wallet.cpp

+{
+    LOCK(cs_wallet);
+    CWalletDB walletdb(*dbw);
+    auto it = std::begin(setKeyPool);


In commit "Add basic HD wallet restore functionality"

Should move this declaration closer to where it's actually used way below.

Should move this declaration closer to where it's actually used way below.

(unchanged)

ryanofsky · 2017-05-05T17:05:46Z

src/wallet/wallet.cpp

+                    throw std::runtime_error(std::string(__func__) + ": read failed");
+
+                // only mark keys on the corresponding chain
+                if (keypool.fInternal == foundInternal) {


In commit "Add basic HD wallet restore functionality"

Shouldn't it be an error if this condition is not true?

Shouldn't it be an error if this condition is not true?

(unchanged)

ryanofsky · 2017-05-05T19:48:49Z

src/validation.cpp

In commit "Make sure we pause immediately if we receive a pause-request"

Would squash this commit into the commit "Add request-halt flag to BlockConnected signal" (along with the other change I suggest moving there) so this is understandable in the correct context.

Would squash this commit into the commit "Add request-halt flag to BlockConnected signal" (along with the other change I suggest moving there) so this is understandable in the correct context.

(unchanged)

ryanofsky · 2017-05-05T19:58:36Z

src/wallet/wallet.cpp

        strUsage += HelpMessageOpt("-flushwallet", strprintf("Run a thread to flush wallet periodically (default: %u)", DEFAULT_FLUSHWALLET));
        strUsage += HelpMessageOpt("-privdb", strprintf("Sets the DB_PRIVATE flag in the wallet db environment (default: %u)", DEFAULT_WALLET_PRIVDB));
        strUsage += HelpMessageOpt("-walletrejectlongchains", strprintf(_("Wallet will not create transactions that violate mempool chain limits (default: %u)"), DEFAULT_WALLET_REJECT_LONG_CHAINS));
+        strUsage += HelpMessageOpt("-hdignoregaplimit", strprintf(_("Ignores the minimum keypool-size warning for HD restore (default: %u)"), DEFAULT_IGNORE_HD_MIN_KEYPOOL_SIZE));


In commit "SetSoftArg the keypool always to the minimum gap limit if HD is enabled"

It seems like it would be a lot harder to for someone to understand what this "ignore gap limit" option does than the PAUSE_SYNC_WHEN_KEYPOOL_SMALLER_THAN option I suggested in another comment. Would be curious to know what you think about it.

The -hdignoregaplimit is for debug purposes only. Our tests run with a keypool size of 1 and therefor would cause troubles running post this PR without a "ignore" option, and I don't think it matter how we "ignore" the gap limit and over a startup argument seems the be the simplest way.

The -hdignoregaplimit is for debug purposes only

Maybe it's not worth fixing, but even as a developer I think "pause sync when keypool is smaller than" is clearer than "ignore hd gap limit" because one name tells you literally what the option does, while the other refers obliquely to what the option doesn't do.

I think "pause sync when keypool is smaller than" is clearer than "ignore hd gap limit"

👍

nit: place this argument in the correct alphabetic order.

ryanofsky · 2017-05-05T19:59:54Z

src/wallet/wallet.cpp

            walletInstance->TopUpKeyPool();
        }
-        if (!walletInstance->CheckKeypoolMinSize()) {
+        if (!walletInstance->CheckKeypoolMinSize() && !GetBoolArg("-hdignoregaplimit", DEFAULT_IGNORE_HD_MIN_KEYPOOL_SIZE)) {


In commit "SetSoftArg the keypool always to the minimum gap limit if HD is enabled"

This seems broken. It's still pausing but just no longer warning that the pause took place?

This seems broken. It's still pausing but just no longer warning that the pause took place?

On second look, this seems ok because CWallet::CheckKeypoolMinSize now checks for "-hdignoregaplimit" and disables the pause.

ryanofsky · 2017-05-05T20:02:26Z

test/functional/wallet-hd.py

        self.stop_node(1)
-        os.remove(self.options.tmpdir + "/node1/regtest/wallet.dat")
+        # we need to delete the complete regtest directory
+        # otherwise node1 would auto-recover all funds in flag the keypool keys as used


In commit "SetSoftArg the keypool always to the minimum gap limit if HD is enabled"

Is this change meant to be part of this commit? I don't think there's an interaction with hdignoregaplimit here.

Is this change meant to be part of this commit? I don't think there's an interaction with hdignoregaplimit here.

(unchanged)

I'm also confused about why wallet-hd.py needs to be updated.

ryanofsky · 2017-05-05T20:08:57Z

src/wallet/wallet.cpp

+
+        // for now, enable block requests and tip updates via the states
+        // this will only be sufficient as long as only a single wallet adjusts these stats
+        // otherwise the net-/validation-logic needs to poll the state over a signal (or similar)


In commit "Ensure we pause wallet sync when the keypool requires extension"

It should be possible to handle this without any polling or notifications by making fPauseBlockRequests and fPauseTipUpdates counters instead of bools. The counters would need to be incremented whenever fSyncPausedUntilKeypoolExt changed from false to true in any wallet, and decremented when it changed from true to false. Block requesting or tip updating would be paused whenever its respective counter was greater than 0.

Yes. Thats a good idea. Do you think this should be done in this PR or can we tackle this once we have multiple places where the sync may get paused?
Counters may also introduce the risk of unwillingly increasing it twice (while only decrease it once).

Do you think this should be done in this PR or can we tackle this once we have multiple places where the sync may get paused?

Maybe, this PR is already pretty complicated, so I wouldn't want to tack this on in extra commits, but it could be nice if implemented to replace the existing "Add option to pause..." commits.

…re key to respect the gap limit

…ving a key

… BlockConnected signal

jonasschnelli · 2017-05-12T08:29:55Z

Needed rebase.
Addressed most of @ryanofsky points.

ryanofsky · 2017-06-08T15:22:10Z

src/validation.cpp

Would squash this commit into the commit "Add request-halt flag to BlockConnected signal" (along with the other change I suggest moving there) so this is understandable in the correct context.

(unchanged)

ryanofsky · 2017-06-08T15:22:38Z

src/wallet/wallet.cpp

+            SyncTransaction(pblock->vtx[i], pindex, i);
+        }
+        if (fSyncPausedUntilKeypoolExt) {
+            requestPause = true;


As you mention, it would be much simpler to call setBlockRequestsPaused(), but, wouldn't it be a massive layer violation? Communicating through the signals doesn't require that the wallet needs to know what the full node parts is really doing. But maybe im overcomplicating things here.

I don't see why it would be a problem to call setBlockRequestsPaused(true) from CWallet::MarkReserveKeysAsUsed, especially if it isn't a problem to call setBlockRequestsPaused(false) from CWallet::EventuallyRescanAfterKeypoolTopUp which the current code already does. It seems like it would just make pausing simpler, and more consistent with unpausing.

ryanofsky · 2017-06-08T15:23:03Z

src/wallet/wallet.cpp

+                if (pindexRescan != block) {
+                    const static std::string pruneError = "Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node)";
+                    uiInterface.ThreadSafeMessageBox(pruneError, "", CClientUIInterface::MSG_ERROR);
+                    StartShutdown();


But there is no guarantee that we won't prune bellow the wallets best block,.. this why this shutdown/protection is here.

Wouldn't just staying paused in this case offer as much protection as briefly unpausing and then shutting down?

ryanofsky · 2017-06-08T15:23:13Z

src/wallet/wallet.cpp

+{
+    LOCK(cs_wallet);
+    CWalletDB walletdb(*dbw);
+    auto it = std::begin(setKeyPool);


Should move this declaration closer to where it's actually used way below.

(unchanged)

ryanofsky · 2017-06-08T15:23:19Z

src/wallet/wallet.cpp

+        if (!walletdb.ReadPool(id, keypool))
+            throw std::runtime_error(std::string(__func__) + ": read failed");
+
+        if (keypool.vchPubKey.GetID() == keyId) {


It would also require to keep the fInternal flags in memory (for the address book internal/external change flagging). This is independently addresses in #10238.

Yeah probably not worth simplifying this if it will be obsoleted by #10238.

ryanofsky · 2017-06-08T15:28:05Z

src/wallet/wallet.cpp

+    size_t extKeypoolSize = KeypoolCountExternalKeys();
+    if (IsHDEnabled() && (extKeypoolSize < HD_RESTORE_KEYPOOL_SIZE_MIN || (setKeyPool.size()-extKeypoolSize) < HD_RESTORE_KEYPOOL_SIZE_MIN)) {
+        // if the remaining keypool size is below the gap limit, refuse to continue with the sync
+        fSyncPausedUntilKeypoolExt = true;


This pausing behavior seems like it should be optional

The "-hdignoregaplimit" argument added in the next commit does make this optional (commit "SetSoftArg the keypool always to the minimum gap limit"), though I still think a single "pause sync when keypool smaller than" check would be a little cleaner than separate "keypool size min" and "ignore gap limit" checks.

ryanofsky · 2017-06-08T15:28:23Z

src/wallet/wallet.cpp

        }
-
+        if (!walletInstance->CheckKeypoolMinSize()) {
+            InitWarning(_("Your keypool size is below the required limit for HD rescans. Wallet synchronisation is now paused until you have refilled the keypool."));


Warning should suggest how to fix the problem, and also ideally also include more background information (maybe consider using my previous suggestion for the -keypool limit warning).

(unchanged)

ryanofsky · 2017-06-08T15:29:14Z

src/wallet/wallet.cpp

            walletInstance->TopUpKeyPool();
        }
-        if (!walletInstance->CheckKeypoolMinSize()) {
+        if (!walletInstance->CheckKeypoolMinSize() && !GetBoolArg("-hdignoregaplimit", DEFAULT_IGNORE_HD_MIN_KEYPOOL_SIZE)) {


This seems broken. It's still pausing but just no longer warning that the pause took place?

On second look, this seems ok because CWallet::CheckKeypoolMinSize now checks for "-hdignoregaplimit" and disables the pause.

ryanofsky · 2017-06-08T18:33:52Z

src/wallet/wallet.cpp

    // HD Restore: Make sure we always have a reasonable keypool size if HD is enabled
    if (walletInstance->IsHDEnabled()) {
-        if (walletInstance->IsCrypted()) {
-            InitWarning(_("Your are using an encrypted HD wallet. In case you recover a HD wallet, you may miss incomming or outgoing funds."));


In commit "SetSoftArg the keypool always to the minimum gap limit if HD is enabled"

It might be a good idea to keep the warning about missing funds in the case where IsCrypted && size < KEYPOOL_SIZE_MIN && GetBool("-hdignoregaplimit"). I also had a suggestion about this warning in
#10240 (comment)

ryanofsky · 2017-06-08T18:50:15Z

src/wallet/wallet.cpp

        }
        else {
-            if (GetArg("-keypool", DEFAULT_KEYPOOL_SIZE) < HD_RESTORE_KEYPOOL_SIZE_MIN ) {
-                InitWarning(_("Your keypool size is below the recommended limit for HD rescans. In case you recover a HD wallet, you may miss incomming or outgoing funds."));


In commit "Make sure we check the keypool min size during startup"

Why drop this warning? It still seems useful to warn about the "-keypool" being too small even if KeypoolCountExternalKeys() is momentarily returning a high number of keys. (I also had another suggestion about this warning at #10240 (comment))

sipa · 2017-06-12T22:31:12Z

Needs rebase.

jnewbery

Needs rebase. I've added a lot of mainly nitty comments. The most important thing to address is to make this compatible with multiwallet.

jnewbery · 2017-06-12T22:06:24Z

src/wallet/wallet.cpp

-
-    for (const CTransactionRef& ptx : vtxConflicted) {
-        SyncTransaction(ptx);
+void CWallet::BlockConnected(const std::shared_ptr<const CBlock>& pblock, const CBlockIndex *pindex, const std::vector<CTransactionRef>& vtxConflicted, bool &requestPause) {


I'm not going to comment on @ryanofsky's other comments regarding commit order (although they all sound sensible). This one should definitely be fixed in commit "Add request-halt flag to BlockConnected signal" since it breaks the build and so breaks git bisect.

jnewbery · 2017-06-12T22:06:38Z

src/net_processing.cpp

    // Make sure pindexBestKnownBlock is up to date, we'll need it.
    ProcessBlockAvailability(nodeid);

+    if (isBlockRequestsPaused())


nit: braces

Please address.

jnewbery · 2017-06-12T22:11:54Z

src/validation.h

 /** Guess verification progress (as a fraction between 0.0=genesis and 1.0=current tip). */
 double GuessVerificationProgress(const ChainTxData& data, CBlockIndex* pindex);

+/**


nit: s/will allow to temporary/will temporarily

jnewbery · 2017-06-12T22:12:06Z

src/validation.h

+bool isBlockRequestsPaused();
+void setBlockRequestsPaused(bool state);
+
+/**


nit: s/will temporary/will temporarily

jnewbery · 2017-06-12T22:14:03Z

src/wallet/rpcwallet.cpp

    pwallet->TopUpKeyPool();

+    // give a hint to the wallet in case we have paused sync (we may have fall bellow the hd gap limit)
+    // this runs synchronous, at least during the resync, we can be sure the keypool can be topped up


nit:

// Give a hint to the wallet in case we have paused sync (we may have fallen bellow the hd gap limit). // This runs synchronously, at least during the resync, we can be sure the keypool can be topped up

jnewbery · 2017-06-12T22:54:15Z

test/functional/wallet-hd-restore.py

+    def run_test (self):
+        tmpdir = self.options.tmpdir
+
+        print("Initialize wallet including backups of unencrypted and encrypted wallet")


Please use self.log.info() instead of print for logging.

jnewbery · 2017-06-12T22:58:12Z

test/functional/wallet-hd-restore.py

+            addr_enc_oldpool = self.nodes[1].getnewaddress()
+
+        # now make sure we retrive an address in the extended pool
+        self.nodes[1].walletpassphrase("test", 10)


Suggest you set the timeout higher, perhaps to 60 seconds. Tests should be robust to bitcoind hanging for several seconds, especially if running in parallel on Travis.

jnewbery · 2017-06-12T23:00:35Z

test/functional/wallet-hd-restore.py

+
+        print("Testing with unencrypted wallet")
+        self.stop_node(1)
+        shutil.rmtree(tmpdir + "/node1/regtest")


please don't do this! It erases the debug.log file. Are you able to be more targeted in what you're erasing?

Please address.

jnewbery · 2017-06-12T23:02:31Z

test/functional/wallet-hd-restore.py

+        assert_equal(self.nodes[1].validateaddress(addr)['hdkeypath'], "m/0'/0'/11'")
+
+        rawch = self.nodes[1].getrawchangeaddress()
+        txid = self.nodes[0].sendtoaddress(addr, 1)


txid isn't used. No need to assign it here or below.

jnewbery · 2017-06-12T23:05:12Z

test/functional/wallet-hd.py

        self.stop_node(1)
-        os.remove(self.options.tmpdir + "/node1/regtest/wallet.dat")
+        # we need to delete the complete regtest directory
+        # otherwise node1 would auto-recover all funds in flag the keypool keys as used


I'm also confused about why wallet-hd.py needs to be updated.

gmaxwell · 2017-06-15T20:05:48Z

Will begin code review post rebase.

Question about the parameters-- Why 20? that is very small, I am not aware of any reason to not have it be more like-- say-- 10,000. With a large number the pause is hopefully seldom/never hit. Electrum uses a very small number because its a single user wallet and has to send all these addresses for processing to a remote server. In a commercial application getting reordering beyond 20 would be very easy. (e.g hand out 30 keys to different users and only the first one makes a payment).

jonasschnelli · 2017-06-15T20:27:07Z

Agree that 20 is probably way to low.
It's just a single constant and I worry more about getting the PR on a level where everything works as expected. Changing the 20 to 1000 then is simple... once the PR is stable, we can also test performance better (maybe between 20 and 10k).

sipa

Some comments already.

Overall question: why is any of this conditional on HD being enabled? I think we want to mark user and topup any key seen on the network at any time.

sipa · 2017-07-12T23:10:44Z

test/functional/wallet-hd-restore.py

+# Copyright (c) 2017 The Bitcoin Core developers
+# Distributed under the MIT software license, see the accompanying
+# file COPYING or http://www.opensource.org/licenses/mit-license.php.
+"""Test Hierarchical Deterministic wallet function."""


Please address.

sipa · 2017-07-12T23:11:07Z

test/functional/wallet-hd-restore.py

+
+        print("Testing with unencrypted wallet")
+        self.stop_node(1)
+        shutil.rmtree(tmpdir + "/node1/regtest")


Please address.

sipa · 2017-07-12T23:11:48Z

src/wallet/wallet.cpp

+        if (walletInstance->IsCrypted()) {
+            InitWarning(_("Your are using an encrypted HD wallet. In case you recover a HD wallet, you may miss incomming or outgoing funds."));
+        }
+        else {


Nit: else on the same line as }

sipa · 2017-07-12T23:12:57Z

src/net_processing.cpp

    // Make sure pindexBestKnownBlock is up to date, we'll need it.
    ProcessBlockAvailability(nodeid);

+    if (isBlockRequestsPaused())


Please address.

jonasschnelli · 2017-07-14T21:22:53Z

Closing in favor of #10830

jonasschnelli force-pushed the 2017/04/hd_rescan branch 2 times, most recently from 4efffdf to 427ea2f Compare April 20, 2017 19:59

jonasschnelli added the Wallet label Apr 20, 2017

jonasschnelli force-pushed the 2017/04/hd_rescan branch 2 times, most recently from fa2ed74 to 3a7dbb6 Compare May 3, 2017 15:10

jonasschnelli force-pushed the 2017/04/hd_rescan branch 4 times, most recently from 7ceb728 to cada726 Compare May 4, 2017 12:49

jonasschnelli changed the title ~~[WIP] Add basic HD wallet restore functionality~~ Add basic HD wallet restore functionality May 4, 2017

jonasschnelli commented May 4, 2017

View reviewed changes

jonasschnelli changed the title ~~Add basic HD wallet restore functionality~~ Add HD wallet auto-restore functionality May 4, 2017

ryanofsky reviewed May 5, 2017

View reviewed changes

laanwj added this to the 0.15.0 milestone May 11, 2017

jonasschnelli added 11 commits May 12, 2017 09:38

[MOVEONLY] move CAffectedKeysVisitor

0024b9c

Add basic HD wallet restore functionality

2a203b7

Add option to pause block requests (is/setBlockRequestsPaused())

68d600b

Add option to pause tip updates (is/setTipUpdatesPaused())

1a0272a

Add request-halt flag to BlockConnected signal

5a10cd3

Wallet: allow to eventually pause verification if keypool requires mo…

5b70a22

…re key to respect the gap limit

Ensure we pause wallet sync when the keypool requires extension

2a8f1f6

Extend wallet hd restore functional test

09de1cb

Make sure we check the keypool min size during startup and when retri…

46060c2

…ving a key

SetSoftArg the keypool always to the minimum gap limit if HD is enabled

bd9e1e8

Make sure we pause immediately if we receive a pause-request over the…

4cbc216

… BlockConnected signal

jonasschnelli force-pushed the 2017/04/hd_rescan branch from 11cccad to 4cbc216 Compare May 12, 2017 08:29

ryanofsky mentioned this pull request Jun 8, 2017

Track keypool entries as internal vs external in memory #10235

Merged

ryanofsky reviewed Jun 8, 2017

View reviewed changes

jnewbery reviewed Jun 12, 2017

View reviewed changes

sipa reviewed Jul 12, 2017

View reviewed changes

jnewbery mentioned this pull request Jul 14, 2017

[WIP] [wallet] keypool restore #10830

Closed

3 tasks

jonasschnelli closed this Jul 14, 2017

ryanofsky mentioned this pull request Jul 19, 2017

[Do not merge] Stop advancing best block and shutdown node if keypool drops below critical threshold #10882

Closed

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

Add HD wallet auto-restore functionality #10240

Add HD wallet auto-restore functionality #10240

Uh oh!

Conversation

jonasschnelli commented Apr 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

unencrypted wallets

encrypted wallets in non pruning mode

encrypted wallets in pruned mode

Uh oh!

ryanofsky commented May 1, 2017

Uh oh!

jonasschnelli commented May 2, 2017

Uh oh!

jonasschnelli commented May 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

unencrypted wallets

encrypted wallets in non pruning mode

encrypted wallets in pruned mode

Uh oh!

jonasschnelli commented May 4, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky May 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonasschnelli commented Apr 20, 2017 •

edited

Loading

jonasschnelli commented May 3, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

ryanofsky May 5, 2017 •

edited

Loading

jonasschnelli commented May 12, 2017 •

edited

Loading