Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets #9662

jonasschnelli · 2017-02-01T13:16:16Z

This mode ('createwallet {"disableprivatekeys": true}') is intended for a sane pure watch-only mode, ideal for a use-case where one likes to use Bitcoin-Core in conjunction with a hardware-wallet or another solutions for cold-storage.

Since we have support for custom change addresses in fundrawtransaction, pure watch-only wallets including coin-selection are possible and do make sense for some use cases.

This new mode disables all forms of private key generation and ensure that no mix between hot and cold keys are possible.

TheBlueMatt · 2017-02-01T21:23:51Z

It seems somewhat strange that this is set per-run and not per-wallet. Indeed, if it were set per-wallet, an easy way to get the intended behavior here is to simply encrypt your wallet with a garbage passphrase such that it can no longer be opened (not to say we shouldn't do this, better UX around that is good, but it might be easier to review/write if it re-used that infrastructure).

laanwj · 2017-02-02T08:03:06Z

Concept ACK. I agree that this would be better as a mode on the wallet instead of yet another startup option.

NicolasDorier · 2017-02-16T01:53:52Z

I would like to rebase on top of that for #9728, can you rebase?
I would switch that on if hdwatchonly is used.

jonasschnelli · 2017-02-17T09:11:11Z

Added two commit.

First commit adds a facility to store and check wallet flags (64bit). Made DISABLE_PRIVATE_KEYS the first flag.
Second commit makes the disablehot function per wallet (no longer a global state)

Disabling private keys on a wallet that already contains private keys is not possible (also the other way around).

jonasschnelli · 2017-02-17T09:37:35Z

qa/rpc-tests/disablehot.py

+        print("restarting node with disablehot=0 (try to re-enable private keys which must not be possible)")
+        stop_nodes(self.nodes)
+        try:
+            self.nodes = start_nodes(self.num_nodes, self.options.tmpdir, [[], ['-disablehot=0']])


@MarcoFalke: any idea how I can make this pass? Right now, staring bitcoind in this case with this setup will cause bitcoind to write to stderr (and halt) which then result in pass=false in rpc-tests.py. But it's actually the correct behaviour.

We might create a assert_start_raises_init_error() method. I will take a look at this tomorrow.

NicolasDorier · 2017-02-20T05:11:45Z

src/wallet/wallet.cpp

@@ -1408,13 +1407,25 @@ bool CWallet::IsHDEnabled()
    return !hdChain.masterKeyID.IsNull();
 }

+void CWallet::SetWalletFlag(uint64_t flag)
+{
+    walletFlags |= flag;


Kind of confusing....
I thought this would be equivalent to CWallet::SetWalletFlags(uint64_t flags, false).

However while CWallet::SetWalletFlags(uint64_t flags, bool memonly) set the flags to the indicated value, CWallet::SetWalletFlag(uint64_t flag) appends to it.

Maybe you should rename to AddWalletFlags.

CWallet::AddWalletFlags(uint64_t flags, book memonly) seems most consistent.

IMO set flags seems most appropriate here. Flags are not getting appended. Either you set or unset IMO. For consistency, we should have a UnsetWalletFlag().
But I agree its kind of confusing that we have a SetWalletFlags (plural) method that is capable or re-setting all 64 flags.

I think this method should be plural, since there is no distinction between a single flag and multiple flags in its operation and it might be useful to be able to do the latter.

Then, of course, you have confusion. So, a verb change in the method name might be useful.

@jonasschnelli the strange thing is that SetWalletFlag switch a bit, when SetWalletFlags set the walletFlags to a specific value. I was expecting SetWalletFlags to switch several bits.

Maybe renaming SetWalletFlags (plural) to OverwriteWalletFlags?

Maybe renaming SetWalletFlags (plural) to OverwriteWalletFlags?

Since this is doing an | I'd call it AddFlags (which conceivably could be paired with a RemoveFlags doing & ~).

NicolasDorier · 2017-02-20T06:33:22Z

qa/rpc-tests/disablehot.py

+        self.num_nodes = 2
+
+    def setup_network(self, split=False):
+        self.nodes = start_nodes(self.num_nodes, self.options.tmpdir, [[], ['-disablehot']])


does the [] arguments is on purpose? because I think it makes -disablehot ignored

We start two nodes here, the first node without startup parameters (thats why there is the []). Only second node has -disablehot.

jonasschnelli · 2017-03-03T15:36:09Z

Needed rebase (#8775).
Travis will fail because of the missing assert_start_raises_init_error (see #9832).

laanwj · 2017-03-06T09:13:54Z

ideal for a use-case where one likes to use Bitcoin-Core in conjunction with a hardware-wallet or another solutions for cold-stogare

Nice, so this guarantees that bitcoind process will contain no private key data at all?
Seems like s a good step towards supporting hardware wallets too.
Concept ACK.

Travis should pass now that #9832 is merged.

jonasschnelli · 2017-03-06T09:31:54Z

The disablehot.py now makes use of the new (#9832) assert_start_raises_init_error call.

Nice, so this guarantees that bitcoind process will contain no private key data at all?

Yes. Event the default key is disabled (while still detecting the first start correctly).

NicolasDorier · 2017-03-13T07:59:14Z

src/wallet/wallet.cpp

+    else if (IsArgSet("-disablehot")) {
+        bool disableHot = GetBoolArg("-disablehot", DEFAULT_DISABLE_HOT_WALLET);
+        LOCK(walletInstance->cs_wallet);
+        if (walletInstance->vchDefaultKey.IsValid() && disableHot) {


I think you should use fFirstRun here instead of walletInstance->vchDefaultKey.IsValid()

At this point fFirstRun is always false. And I think this also works in conjunction with salvagewallet.

Indeed. Might be out of this PR matter, in the case of hdwatchonly, walletInstance->vchDefaultKey.IsValid() will be true. So this would mean disabledHot is incompatible with hdwatchonly mode ?

OK forget what I said, there is no reason to have disabledHot with hdwatchonly at same time.

This should at least be abstracted somehow. vchDefaultKey's existence is not exactly identical to "does this wallet have keys?"

jonasschnelli · 2017-03-29T14:44:25Z

Rebased.

laanwj · 2017-05-02T13:32:20Z

Needs rebase again (sorry)
utACK otherwise.

jonasschnelli · 2017-05-04T13:11:09Z

Rebased.

ryanofsky

utACK 9b39bf94f168ab82707df91f21cffea0b286f919

The commit history of this PR is messy though. I would suggest moving the "Add facility to store wallet flags (64 bits)" commit to be first, then then squashing all the other changes down into single commit following that.

ryanofsky · 2017-05-04T16:00:10Z

src/wallet/wallet.cpp

@@ -3915,6 +3948,7 @@ bool CWallet::ParameterInteraction()
    nTxConfirmTarget = GetArg("-txconfirmtarget", DEFAULT_TX_CONFIRM_TARGET);
    bSpendZeroConfChange = GetBoolArg("-spendzeroconfchange", DEFAULT_SPEND_ZEROCONF_CHANGE);
    fWalletRbf = GetBoolArg("-walletrbf", DEFAULT_WALLET_RBF);
+    fDisableHotKeys = GetBoolArg("-disablehot", DEFAULT_DISABLE_HOT_WALLET);


In commit "Add -disablehot option to ensure pure watchonly-wallets"

I don't understand why we want to call these "hot keys" and not "private keys," but I guess I'm out of the loop on terminology not knowing precisely what a "hot key" is.

ryanofsky · 2017-05-04T16:29:33Z

qa/rpc-tests/disablehot.py

+            self.nodes[1].getnewaddress()
+            raise AssertionError("Wallet can derive private keys while -disablehot is enabled")
+        except JSONRPCException as e:
+            assert('Hot key' in e.error['message'])


In commit "Add -disablehot option to ensure pure watchonly-wallets"

Consider using assert_raises_jsonrpc. (It's less verbose)

ryanofsky · 2017-05-04T16:54:41Z

src/wallet/wallet.cpp

@@ -2497,6 +2500,11 @@ bool CWallet::CreateTransaction(const std::vector<CRecipient>& vecSend, CWalletT
                        //  post-backup change.

                        // Reserve a new key pair from key pool
+                        if (fDisableHotKeys) {


In commit "Add -disablehot option to ensure pure watchonly-wallets"

Do you think it might be better to fail earlier in CreateTransaction, regardless of the nChange > 0 condition? I'm thinking it might be, just so calls would fail consistently instead of sometimes randomly succeeding. But I don't have much understanding of the real-world use-cases for this, so this is just a thought.

Considering adding a code comment here explaining more.

Falling earlier would disallow creating watch-only transactions (over fundrawtransaction).

ryanofsky · 2017-05-04T17:03:59Z

src/qt/walletmodel.cpp

@@ -705,7 +705,8 @@ bool WalletModel::hdEnabled() const

 bool WalletModel::hotKeysDisabled() const
 {
-    return fDisableHotKeys;
+    return (pwalletMain->IsWalletFlagSet(WALLET_FLAG_DISABLE_HOT_KEYS));
+


In commit "Make -disablehot per wallet (remove global state)"

Extra newline here

ryanofsky · 2017-05-04T18:53:59Z

src/wallet/wallet.cpp

@@ -1408,13 +1407,25 @@ bool CWallet::IsHDEnabled()
    return !hdChain.masterKeyID.IsNull();
 }

+void CWallet::SetWalletFlag(uint64_t flag)
+{
+    walletFlags |= flag;


Maybe renaming SetWalletFlags (plural) to OverwriteWalletFlags?

Since this is doing an | I'd call it AddFlags (which conceivably could be paired with a RemoveFlags doing & ~).

ryanofsky · 2017-05-04T19:03:45Z

src/wallet/wallet.cpp

+        }
+        bool hotKeys = walletInstance->IsWalletFlagSet(WALLET_FLAG_DISABLE_HOT_KEYS);
+        if (hotKeys && !disableHot) {
+            InitError(strprintf(_("Error loading %s: You can't enable hot keys once you have initialized a wallet with disabled hot keys"), walletFile));


Add -disablehot mode: a sane mode for watchonly-wallets

Maybe the error message could suggest passing -disablehot to avoid the problem. I think it would make the context of the error easier to understand for someone not expecting it.

jonasschnelli · 2017-05-05T07:27:38Z

Completely rewrote the commit history (as reported by @ryanofsky it was messy).
Fixed @ryanofsky points

No strong opinion if this should be called -disableprivatekeys (which somehow nails it but may confuse people who just want cold key storage). Other opinions?�

ryanofsky · 2017-05-05T14:40:42Z

utACK fcea55a6ec6be57ee96458bde6fb24656269d3ee

Changes from previous review: pwalletMain removal, SetWalletFlag rename, error message tweaks, assert_raises_jsonrpc usage, and history cleanup.

…e for watchonly-wallets Summary: a3fa4d6a6acf19d640a1d5879a00aa1f059e2380 QA: Fix bug in -usecli logic that converts booleans to non-lowercase strings (Jonas Schnelli) 4704e5f074e57782d058404a594a7313cf170cf0 [QA] add createwallet disableprivatekey test (Jonas Schnelli) c7b8f343e99d9d53ea353ddce9a977f1886caf30 [Qt] Disable creating receive addresses when private keys are disabled (Jonas Schnelli) 2f15c2bc20d583b4c1788da78c9c635c36e03ed0 Add disable privatekeys option to createwallet (Jonas Schnelli) cebefba0855cee7fbcb9474b34e6779369e8e9ce Add option to disable private keys during internal wallet creation (Jonas Schnelli) 9995a602a639b64a749545b7c3bafbf67f97324f Add facility to store wallet flags (64 bits) (Jonas Schnelli) Pull request description: This mode ('createwallet {"disableprivatekeys": true}') is intended for a sane pure watch-only mode, ideal for a use-case where one likes to use Bitcoin-Core in conjunction with a hardware-wallet or another solutions for cold-storage. Since we have support for custom change addresses in `fundrawtransaction`, pure watch-only wallets including coin-selection are possible and do make sense for some use cases. This new mode disables all forms of private key generation and ensure that no mix between hot and cold keys are possible. Tree-SHA512: 3ebe7e8d54c4d4e5f790c348d4c292d456f573960a5b04d69ca5ef43a9217c7e7671761c6968cdc56f9a8bc235f3badd358576651af9f10855a0eb731f3fc508 Backport of Core PR9662 bitcoin/bitcoin#9662 Depends on D4175 Test Plan: make check test_runner.py bitcoin-qt Help -> Debug -> Console createwallet noprivkey true Select noprivkey wallet in the main window In the `Receive` menu, the `Request Payment` button should be greyed out and not clickable. {F4088184} Reviewers: deadalnix, Fabien, jasonbcox, O1 Bitcoin ABC, #bitcoin_abc Reviewed By: deadalnix, Fabien, O1 Bitcoin ABC, #bitcoin_abc Differential Revision: https://reviews.bitcoinabc.org/D4304

…ane mode for watchonly-wallets a3fa4d6 QA: Fix bug in -usecli logic that converts booleans to non-lowercase strings (Jonas Schnelli) 4704e5f [QA] add createwallet disableprivatekey test (Jonas Schnelli) c7b8f34 [Qt] Disable creating receive addresses when private keys are disabled (Jonas Schnelli) 2f15c2b Add disable privatekeys option to createwallet (Jonas Schnelli) cebefba Add option to disable private keys during internal wallet creation (Jonas Schnelli) 9995a60 Add facility to store wallet flags (64 bits) (Jonas Schnelli) Pull request description: This mode ('createwallet {"disableprivatekeys": true}') is intended for a sane pure watch-only mode, ideal for a use-case where one likes to use Bitcoin-Core in conjunction with a hardware-wallet or another solutions for cold-storage. Since we have support for custom change addresses in `fundrawtransaction`, pure watch-only wallets including coin-selection are possible and do make sense for some use cases. This new mode disables all forms of private key generation and ensure that no mix between hot and cold keys are possible. Tree-SHA512: 3ebe7e8d54c4d4e5f790c348d4c292d456f573960a5b04d69ca5ef43a9217c7e7671761c6968cdc56f9a8bc235f3badd358576651af9f10855a0eb731f3fc508

jonasschnelli added the Wallet label Feb 1, 2017

jonasschnelli force-pushed the 2017/02/disable_hot branch from 6763740 to dd6c8fc Compare February 1, 2017 13:47

jonasschnelli mentioned this pull request Feb 9, 2017

Can create External HD wallet with -externalhd #9728

Closed

jonasschnelli force-pushed the 2017/02/disable_hot branch from dd6c8fc to cd93c2d Compare February 17, 2017 09:08

jonasschnelli commented Feb 17, 2017

View reviewed changes

jonasschnelli force-pushed the 2017/02/disable_hot branch from cd93c2d to e581d84 Compare February 17, 2017 09:40

NicolasDorier reviewed Feb 20, 2017

View reviewed changes

NicolasDorier mentioned this pull request Feb 23, 2017

[qa] assert_start_raises_init_error #9832

Merged

jonasschnelli force-pushed the 2017/02/disable_hot branch from e581d84 to f0a090f Compare March 3, 2017 15:35

jonasschnelli force-pushed the 2017/02/disable_hot branch from f0a090f to 9549e2c Compare March 6, 2017 09:29

NicolasDorier reviewed Mar 13, 2017

View reviewed changes

jonasschnelli force-pushed the 2017/02/disable_hot branch from 9549e2c to a0b3e09 Compare March 29, 2017 14:44

jonasschnelli force-pushed the 2017/02/disable_hot branch from a0b3e09 to 720b996 Compare April 2, 2017 08:51

jonasschnelli force-pushed the 2017/02/disable_hot branch from 72dfbb3 to 9b39bf9 Compare May 4, 2017 13:10

ryanofsky reviewed May 4, 2017

View reviewed changes

jonasschnelli force-pushed the 2017/02/disable_hot branch 2 times, most recently from 6cf6cd9 to fcea55a Compare May 5, 2017 07:24

adamjonas mentioned this pull request Dec 18, 2020

Ability to freeze / erase private keys #1653

Closed

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

Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets #9662

Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets #9662

Conversation

jonasschnelli commented Feb 1, 2017 • edited

TheBlueMatt commented Feb 1, 2017 • edited

laanwj commented Feb 2, 2017

NicolasDorier commented Feb 16, 2017 • edited

jonasschnelli commented Feb 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NicolasDorier Feb 20, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NicolasDorier Feb 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonasschnelli commented Mar 3, 2017

laanwj commented Mar 6, 2017 • edited

jonasschnelli commented Mar 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonasschnelli commented Mar 29, 2017

laanwj commented May 2, 2017

jonasschnelli commented May 4, 2017

ryanofsky left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonasschnelli commented May 5, 2017

ryanofsky commented May 5, 2017

jonasschnelli commented Feb 1, 2017 •

edited

TheBlueMatt commented Feb 1, 2017 •

edited

NicolasDorier commented Feb 16, 2017 •

edited

NicolasDorier Feb 20, 2017 •

edited

NicolasDorier Feb 22, 2017 •

edited

laanwj commented Mar 6, 2017 •

edited