Skip to content

Conversation

@Eirik0
Copy link
Contributor

@Eirik0 Eirik0 commented Aug 28, 2018

Includes code adapted from upstream PR bitcoin/bitcoin#8323

Closes #3218.

@Eirik0 Eirik0 self-assigned this Aug 28, 2018
@Eirik0 Eirik0 requested review from daira and str4d August 28, 2018 22:51
@Eirik0 Eirik0 added A-wallet Area: Wallet A-rpc-interface Area: RPC interface NU1-sapling Network upgrade: Sapling-specific tasks labels Aug 28, 2018
@bitcartel
Copy link
Contributor

@Eirik0 Can you rebase on master? I rebased but building results in errors, such as:

wallet/rpcdump.cpp:33:7: error: redefinition of ‘class GetSpendingKeyForPaymentAddress’
 class GetSpendingKeyForPaymentAddress : public boost::static_visitor<libzcash::SpendingKey>
       ^
In file included from wallet/rpcdump.cpp:15:0:
wallet/wallet.h:1334:7: error: previous definition of ‘class GetSpendingKeyForPaymentAddress’
 class GetSpendingKeyForPaymentAddress : public boost::static_visitor<boost::optional<libzcash::SpendingKey>>
       ^

@Eirik0 Eirik0 force-pushed the 3218-sapling-import-export-wallet branch from 0c7c283 to cf52125 Compare September 5, 2018 17:03
@Eirik0
Copy link
Contributor Author

Eirik0 commented Sep 5, 2018

Pushed a commit to fix the build errors. The issue was that the class GetSpendingKeyForPaymentAddress had moved in my PR and had moved and been updated in another.

Copy link
Contributor

@bitcartel bitcartel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works in testing. I do have some review comments.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have a log parameter? If just for developer debugging, we should consider removing the parameter and the log messages associated with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is this way because z_importwallet logged each address before it imported it where as z_importkey didn't, and I wanted to be able to reuse the visitor we created for z_importkey.

I could change AddSpendingKeyToWallet to return a pair of the result and an optional address and remove the logging from inside the visitor which might be more correct, but feels clunkier. I'd also be happy to remove the logging, but I can see use cases where that might be helpful. Let me know what you think or if you have a better idea of how to do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that makes sense. Looks good then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be able to rebase and merge this with earlier commits "Add sapling spending keys to z_exportwallet" and/or "Move visitor class" to clean up the function GetSpendingKeyForPaymentAddress().

@zkbot
Copy link
Contributor

zkbot commented Sep 11, 2018

☔ The latest upstream changes (presumably #3492) made this pull request unmergeable. Please resolve the merge conflicts.

@bitcartel
Copy link
Contributor

This PR also needs to import and export SaplingExtendedSpendingKey.

Currently, z_importkey and z_exportkey work with a SaplingSpendingKey. If the RPC interface will support both SaplingSpendingKey and SaplingExtendedSpendingKey, then import and export wallet should also support both.

@Eirik0 Eirik0 force-pushed the 3218-sapling-import-export-wallet branch from cf52125 to bbf37c7 Compare September 11, 2018 22:31
@Eirik0
Copy link
Contributor Author

Eirik0 commented Sep 11, 2018

Rebased and force pushed to address conflicts with #3492.

@Eirik0 Eirik0 force-pushed the 3218-sapling-import-export-wallet branch 2 times, most recently from 9dd7c15 to 3716a1c Compare September 12, 2018 11:04
@Eirik0
Copy link
Contributor Author

Eirik0 commented Sep 12, 2018

See comments in #3218 regarding bitcoin/bitcoin#8323

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

masterkeyid should not be here and is removed in a later commit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you end up rebasing the PR, please squash the later commit into this one.

@Eirik0 Eirik0 force-pushed the 3218-sapling-import-export-wallet branch from 42d53ca to 51c1c3d Compare September 12, 2018 22:57
@str4d str4d changed the title 3218 sapling import export wallet Add Sapling support to z_importwallet and z_exportwallet Sep 13, 2018
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For diversified addresses, this will print the same spending key multiple times, each with a different zaddr. That's probably fine, though it might be a little confusing to users who open the file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be beneficial to include the diversifier along with the address?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The address already includes the diversifier, so I don't think so.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're moving it for accessibility, please move it to the bottom of wallet.h / wallet.cpp with the other generalisations (see there for how to structure it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you rebase this PR to move AddSpendingKeyToWallet into wallet.h, please refactor this into the previous commit (that added SpendingKeyAddResult).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be modified to:

metadata.hdKeypath = "m/32'/" + std::to_string(Params().BIP44CoinType()) + "'/" + std::to_string(hdChain.saplingAccountCounter) + "'";

You could make Params().BIP44CoinType() a variable after auto m so you can reuse it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this comment (wasn't in the commit, and doesn't apply to us in the way it was intended upstream).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit lost its authorship details, but it's pretty trivial, so meh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this one it merged in just fine, but was not correct for zcash. I did a git cherry-pick ... -n, and a git commit -e. Not sure what happened...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to put this at the top of the file, as part of the header (i.e. after the * Best block... line), since this seed is what we would use for deterministic t-addrs if we bring that in, and as-is it will end up "stranded" in the middle-to-end of the backup file if the user's wallet contains many t-addrs. Sorry that it makes your test harder to write...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should be able to set the four new parameters as defaults in the operator() declaration, so that you don't have to specify them in these other locations. Then again, we only use this visitor in these two locations, so maybe explicit is better...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What will this do if hdKeypath or seedFp are empty/null (as for a key imported via z_importkey)? If empty I assume we just get additional whitespace in the file, but seedFp.IsNull() is when it is the all-zeroes array, which I think would get printed out here. We might need to be more verbose here in order to only add these two if they are meaningfully-filled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, I think the import logic will break with this as-is. hdKeypath will be empty, and thus nothing prints for it, but seedFp will print all-zeroes hex. Then on importing, seedFp will be parsed as the third item in the list, and thus be incorrectly interpreted as hdKeypath.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should test importing a key with z_importkey before exporting with z_exportwallet; those keys should only have two parameters.

@Eirik0 Eirik0 force-pushed the 3218-sapling-import-export-wallet branch from 51c1c3d to b37dc4e Compare September 15, 2018 00:36
@Eirik0
Copy link
Contributor Author

Eirik0 commented Sep 15, 2018

Addressed @str4d's comments

{
AssertLockHeld(cs_wallet); // mapZKeyMetadata
AssertLockHeld(cs_wallet); // mapSproutZKeyMetadata
// TODO: Add Sapling support
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment now stale?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it is, as we now use separate functions to generate Sprout and Sapling keys.

Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ut(ACK+cov)

// Don't throw error in case a key is already there
auto addr = sk.address();
if (log){
LogPrint("zrpc", "Importing zaddr %s...\n", EncodePaymentAddress(addr));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this log line now always gets printed, instead of only when importing.

auto addr = sk.DefaultAddress();
{
if (log){
LogPrint("zrpc", "Importing zaddr %s...\n", EncodePaymentAddress(addr));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@str4d str4d added this to the v2.0.1 milestone Sep 19, 2018
@str4d
Copy link
Contributor

str4d commented Sep 19, 2018

@zkbot r+

@zkbot
Copy link
Contributor

zkbot commented Sep 19, 2018

📌 Commit b37dc4e has been approved by str4d

zkbot added a commit that referenced this pull request Sep 19, 2018
Add Sapling support to z_importwallet and z_exportwallet

Includes code adapted from upstream PR bitcoin/bitcoin#8323

Closes #3218.
@zkbot
Copy link
Contributor

zkbot commented Sep 19, 2018

⌛ Testing commit b37dc4e with merge 25c3f90...

@zkbot
Copy link
Contributor

zkbot commented Sep 19, 2018

☀️ Test successful - pr-merge
Approved by: str4d
Pushing 25c3f90 to master...

@zkbot zkbot merged commit b37dc4e into zcash:master Sep 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rpc-interface Area: RPC interface A-wallet Area: Wallet NU1-sapling Network upgrade: Sapling-specific tasks

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants