From ddea44a27e9f5609751cc3dd0ccbe6b915d65c4e Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 13 Oct 2016 16:56:27 -0500 Subject: [PATCH] Update comments --- qa/rpc-tests/wallet_nullifiers.py | 2 +- src/wallet/wallet.h | 10 ++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/qa/rpc-tests/wallet_nullifiers.py b/qa/rpc-tests/wallet_nullifiers.py index dcb634347..7efd70f6a 100755 --- a/qa/rpc-tests/wallet_nullifiers.py +++ b/qa/rpc-tests/wallet_nullifiers.py @@ -119,7 +119,7 @@ class WalletNullifiersTest (BitcoinTestFramework): # Parallel encrypted wallet can't cache nullifiers for received notes, # and therefore can't detect spends. So it sees a balance corresponding # to the sum of both notes it received (one as change). - # TODO: Devise a way to avoid this issue (#) + # TODO: Devise a way to avoid this issue (#1528) assert_equal(self.nodes[1].z_getbalance(myzaddr), zsendmanynotevalue + zaddrremaining) # send node 2 zaddr on node 1 to taddr diff --git a/src/wallet/wallet.h b/src/wallet/wallet.h index 015da56e5..fafad6d12 100644 --- a/src/wallet/wallet.h +++ b/src/wallet/wallet.h @@ -208,9 +208,10 @@ public: * * It's okay to cache the nullifier in the wallet, because we are storing * the spending key there too, which could be used to derive this. - * If PR #1210 is merged, we need to revisit the threat model and decide - * whether it is okay to store this unencrypted while the spending key is - * encrypted. + * If the wallet is encrypted, this means that someone with access to the + * locked wallet cannot spend notes, but can connect received notes to the + * transactions they are spent in. This is the same security semantics as + * for transparent addresses. */ boost::optional nullifier; @@ -758,9 +759,6 @@ public: * * - Restarting the node with -reindex (which operates on a locked wallet * but with the now-cached nullifiers). - * - * Several rounds of this may be required to incrementally fill the - * nullifier caches of discovered notes. */ std::map mapNullifiersToNotes;