Add Sapling support to z_importkey, z_exportkey #3392

arcalinea · 2018-07-12T07:10:25Z

Add Sapling support to z_importkey and z_exportkey

str4d · 2018-07-12T21:37:33Z

src/wallet/rpcdump.cpp

+        }
+
+        return EncodeSpendingKey(sk);
+    }


Move all this into a boost::static_visitor<SpendingKey>. See #3345 for an example. Then this function would become:

... auto sk = boost::apply_visitor(GetSpendingKeyForPaymentAddress(pwalletMain), address); return EncodeSpendingKey(sk); }

It should be fine to throw inside the visitor.

str4d · 2018-07-12T21:38:37Z

src/wallet/rpcdump.cpp

-                return NullUniValue;
+    // Sapling support
+    bool isValidKey = boost::get<libzcash::SproutSpendingKey>(&spendingkey) != nullptr || boost::get<libzcash::SaplingSpendingKey>(&spendingkey) != nullptr;
+    assert(isValidKey);


There's already an IsValidSpendingKey(spendingkey) check above here, so these two lines can be removed.

str4d · 2018-07-12T22:09:11Z

src/wallet/rpcdump.cpp

-        if (fRescan) {
-            pwalletMain->ScanForWalletTransactions(chainActive[nRescanHeight], true);
+    } else {
+        auto sk = boost::get<libzcash::SaplingSpendingKey>(spendingkey);


Move these sections into a boost::static_visitor<bool>, with the boolean indicating whether we should return early (from inside the fIgnoreExistingKey check). This function would become:

... auto keyExists = boost::apply_visitor(AddSpendingKeyToWallet(pwalletMain), spendingkey); if (keyExists) { return NullUniValue; } // whenever a key is imported, ... ...

str4d · 2018-07-12T22:10:29Z

src/wallet/rpcdump.cpp

-    return EncodeSpendingKey(k);
+    // Sapling support
+    bool isValidAddr = boost::get<libzcash::SproutPaymentAddress>(&address) != nullptr || boost::get<libzcash::SaplingPaymentAddress>(&address) != nullptr;
+    assert(isValidAddr);


There's already an IsValidPayamentAddress(address) check above here, so these two lines can be removed.

But despite that, there was an assert there before that address was not nullptr. Why should we remove it now?

The assert was there specifically so that we would get a crash if someone tried to use a Sapling address before support was added. Now that GetSpendingKeyForPaymentAddress is implemented, we don't need these explicit nullptr checks, because if we ever add a new address type, all the boost::static_visitors will immediately start complaining that they aren't covering all cases 🙂

So please remove these two lines.

str4d

The removal of the nullptr checks is blocking.

str4d · 2018-07-19T17:31:21Z

src/wallet/rpcdump.cpp

+                    throw JSONRPCError(RPC_WALLET_ERROR, "Error adding spending key to wallet");
+                }
+
+                m_wallet->mapSaplingZKeyMetadata[addr].nCreateTime = 1;


Hmm, we should think about how this metadata is used, and whether it should index on addr or fvk.

Will it still be used on addresses? Not a lot of instances in the code

Okay, this data is stored in order to figure out when rescanning how many blocks can be skipped (that won't contain transactions for any of the known addresses). So I think it makes sense to store SaplingFullViewingKey instead of SaplingPaymentAddress, as fvk uniquely corresponds to the key that will be used to scan (both for incoming transactions, and in future for recovering outgoing transaction data). However, this is entirely an in-memory decision, so we can just make an issue, and handle it later (when we update ScanForWalletTransactions() to catch all Sapling (and Sprout) transactions without needing to reindex).

Filed issue

str4d · 2018-07-19T17:38:59Z

src/wallet/rpcdump.cpp

+        }
+    }
+
+    bool operator()(const libzcash::InvalidEncoding& no) const { return true; }


This is probably fine; or you could throw an error here (this case should never be triggered, as we call IsValidSpendingKey() first which ensures that spendingkey is not an InvalidEncoding, so getting here would be an implementation error).

str4d · 2018-07-19T17:42:32Z

src/wallet/rpcdump.cpp

-    return EncodeSpendingKey(k);
+    // Sapling support
+    bool isValidAddr = boost::get<libzcash::SproutPaymentAddress>(&address) != nullptr || boost::get<libzcash::SaplingPaymentAddress>(&address) != nullptr;
+    assert(isValidAddr);


The assert was there specifically so that we would get a crash if someone tried to use a Sapling address before support was added. Now that GetSpendingKeyForPaymentAddress is implemented, we don't need these explicit nullptr checks, because if we ever add a new address type, all the boost::static_visitors will immediately start complaining that they aren't covering all cases 🙂

So please remove these two lines.

str4d

Please squash the final cleanup commit into the second-to-last commit. Otherwise, ACK 🙂

str4d · 2018-07-25T12:57:05Z

src/wallet/rpcdump.cpp

+                    throw JSONRPCError(RPC_WALLET_ERROR, "Error adding spending key to wallet");
+                }
+
+                m_wallet->mapSaplingZKeyMetadata[addr].nCreateTime = 1;


Okay, this data is stored in order to figure out when rescanning how many blocks can be skipped (that won't contain transactions for any of the known addresses). So I think it makes sense to store SaplingFullViewingKey instead of SaplingPaymentAddress, as fvk uniquely corresponds to the key that will be used to scan (both for incoming transactions, and in future for recovering outgoing transaction data). However, this is entirely an in-memory decision, so we can just make an issue, and handle it later (when we update ScanForWalletTransactions() to catch all Sapling (and Sprout) transactions without needing to reindex).

bitcartel · 2018-07-26T15:43:50Z

@arcalinea I'm reviewing right now; can you push the cleanup per @str4d's review? Thanks.

bitcartel

I squashed the last two commits into one per str4d's review comment, rebased on master (clean) and force pushed.

bitcartel · 2018-07-30T01:46:58Z

@zkbot r+

zkbot · 2018-07-30T01:46:58Z

📌 Commit 501de64 has been approved by bitcartel

zkbot · 2018-07-30T04:04:17Z

⌛ Testing commit 501de64 with merge 28a8d1d...

Add Sapling support to z_importkey, z_exportkey Add Sapling support to `z_importkey` and `z_exportkey`

zkbot · 2018-07-30T08:36:30Z

☀️ Test successful - pr-merge
Approved by: bitcartel
Pushing 28a8d1d to master...

arcalinea added A-wallet Area: Wallet A-rpc-interface Area: RPC interface NU1-sapling Network upgrade: Sapling-specific tasks labels Jul 12, 2018

arcalinea added this to the v2.0.0 milestone Jul 12, 2018

arcalinea self-assigned this Jul 12, 2018

arcalinea requested review from bitcartel and str4d July 12, 2018 07:10

str4d reviewed Jul 12, 2018

View reviewed changes

str4d requested changes Jul 19, 2018

View reviewed changes

mdr0id requested a review from gtank July 23, 2018 18:29

str4d approved these changes Jul 25, 2018

View reviewed changes

Jay Graber added 4 commits July 29, 2018 16:15

Add Sapling support to z_exportkey

2afc8eb

Add Sapling support to z_importkey

dd4c8a3

Add Sapling to rpc_wallet_z_importexport test

8dd1dbc

Refactor into visitors and throw errors for invalid key or address.

501de64

bitcartel force-pushed the sapling_z_importexport_keys branch from a728d52 to 501de64 Compare July 30, 2018 01:46

bitcartel approved these changes Jul 30, 2018

View reviewed changes

zkbot added a commit that referenced this pull request Jul 30, 2018

Auto merge of #3392 - arcalinea:sapling_z_importexport_keys, r=bitcartel

28a8d1d

Add Sapling support to z_importkey, z_exportkey Add Sapling support to `z_importkey` and `z_exportkey`

zkbot merged commit 501de64 into zcash:master Jul 30, 2018

str4d mentioned this pull request Jul 30, 2018

Extend RPC to be able to import and export Sapling keys #3218

Closed

4 tasks

str4d mentioned this pull request Jul 30, 2018

Add Sapling support to wallet RPCs #3063

Closed

14 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Sapling support to z_importkey, z_exportkey #3392

Add Sapling support to z_importkey, z_exportkey #3392

arcalinea commented Jul 12, 2018

str4d Jul 12, 2018

str4d Jul 12, 2018

str4d Jul 12, 2018

str4d Jul 12, 2018

arcalinea Jul 17, 2018

str4d Jul 19, 2018

str4d left a comment

str4d Jul 19, 2018

arcalinea Jul 19, 2018

str4d Jul 25, 2018

bitcartel Jul 29, 2018

str4d Jul 19, 2018

str4d Jul 19, 2018

str4d left a comment

str4d Jul 25, 2018

bitcartel commented Jul 26, 2018

bitcartel left a comment •

edited

Loading

bitcartel commented Jul 30, 2018

zkbot commented Jul 30, 2018

zkbot commented Jul 30, 2018

zkbot commented Jul 30, 2018

Add Sapling support to z_importkey, z_exportkey #3392

Add Sapling support to z_importkey, z_exportkey #3392

Conversation

arcalinea commented Jul 12, 2018

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

str4d 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

str4d left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bitcartel commented Jul 26, 2018

bitcartel left a comment • edited Loading

Choose a reason for hiding this comment

bitcartel commented Jul 30, 2018

zkbot commented Jul 30, 2018

zkbot commented Jul 30, 2018

zkbot commented Jul 30, 2018

bitcartel left a comment •

edited

Loading