Jack Grigg
9 years ago
No known key found for this signature in database
GPG Key ID: 6A6914DAFBEA00DA
2 changed files with
5 additions and
7 deletions
-
qa/rpc-tests/wallet_nullifiers.py
-
src/wallet/wallet.h
|
|
@ -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 |
|
|
|
|
|
@ -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<uint256> 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<uint256, JSOutPoint> mapNullifiersToNotes; |
|
|
|
|
|
|
|