agi
October 20, 2022, 9:36am
1
Is there already a wallet that supports importing Orchard Viewing Keys?
In more details, I need
to upload Orchard Viewing Keys (not spending keys)
to get Orchard shielded utxos with up-to-date witnesses
compatibility with testnet
I’am aware that there are many affords and grants to implement Orchard, but I’m getting totally lost in their current status.
@hanh @adityapk00 @zancas @str4d ?
cc @prusnak
2 Likes
Described in the Zcash protocol spec 5.6.4, currently there is not support for this, I’ll dig around more:
There is no Bech32[m] encoding defined for an individual Orchard full viewing key; instead use a unified full
opened 10:04PM - 15 Mar 22 UTC
use case
F-selective-disclosure
A-rpc-interface
## Is your feature request related to a problem? Please describe.
- Export and … import of unified full viewing keys is important for maintaining a balance view for cold storage wallets and for auditing purposes.
- Export of incoming viewing keys is important for applications such as ZecWallet and for merchant terminal applications.
opened 08:31PM - 09 May 22 UTC
A-wallet
use case
A-rpc-interface
## Describe the solution you'd like
The ability to export (and subsequently imp… ort) a UA without the need to perform a full backup (restore) of the wallet.
## Additional context
In the application the zaddress essentially functions as a customer account which allowed for us effectively implement credit/debit process flows. The end user/client (in some cases the client is a micro-service) logs into portion of the application where user/client is allowed to interact with application logic - UI to API for human, API for micro-service clients. Following the login and session attach process a micro-service is launched and tied to the specific session life cycle where a spending key is added/injected into the wallet on the new ephemeral node using z_import rpc call. The ability for the application to spend funds on behalf of the user/client exists as a capability for the duration of the session. This process is currently implemented and functions using 4.6.0 and no longer functions in 4.7.0 using UA.
## Alternatives you've considered
As we began to work with 4.7.0 it did catch our attention that z_getaddressforaccount did allow one to specify sapling or orchard pools individually but even with a single pool identified z_export did not function as in the past or as anticipated.
Storing the entire ephemeral wallet could also be reconsidered but we'd have to intercept/grab the wallet at the end of the session and create/place/inject the wallet at the start of the session. It does not appear that the rpc call (z_exportwallet) will allow one to get the full contents of the wallet as only the path is returned. (Perhaps getting the full wallet as an encoded string is an undocumented flag?) In contrast the z_export key returns the key of the zaddrress of interest as a string which is useful and only requires the single rpc call.
We began our project using a flow that injected/extracted entire wallet.dat files but the wallet in/out moves application processes out of the developer space of the application and begins to put this process into the operations realm -- not always a bad thing but would require more coordination between developers and sysadmins/ops. More hands and more steps can correlate to more issues. The single z_exportkey rpc call seems cleaner.
It is our hope that we can maintain our present structure and logic flows where the key is created in our primary full node (node pool actually where rescan I/O can be controlled/monitored -- it pretty much acts as a key server) and a copy of the address specific to the user/service is stored without having to create a new transaction to move user/client funds to the address in our "key server" to the "ephemeral" micro-service node.
We have also considered directly accessing the database file (maybe some kind of side card routine) might be an option but this would seem to add the extra steps just as associated with the moving wallet files themselves around and could also introduce some fragility. We decided that control of the wallet.dat file was probably left best to the concern of the zcashd node.
Running a z_exportwallet and parsing out what we need from the backup file could be considered but still extra steps and not much of a gain over injecting/extracting entire files. Now, if z_exportwallet could send the same content that is written to the z_exportwallet generated file that would present a possible work around (just parsing) to keep this process in developer space as opposed to ops space. (Internally we consider touching persistent storage of our Stateful sets and HashiCorp service part of ops space.)
A z_exportkey (and a z_importkey rescan from a specified block level for a specific address) is preferred.
If this (these) methods could be brought forward to function with UA that would be very much appreciated.
agi
October 20, 2022, 2:41pm
3
Described in the Zcash protocol spec 5.6.4 …
I’m asking something else.
Yeah, Orchard keys and addresses should be shared in unified format.
My question is: Is there already a wallet to which I can import my unified full viewing key containing an Orchard fvk?
agi
October 20, 2022, 2:42pm
4
No, currently not supported. I raised the issue about how I personally thought seed and key imports (or at least one method) should be prioritized in the following release.
It’s an issue that I’m definitely tracking and I will post any updates about it that I see
zancas
October 26, 2022, 6:05pm
8
We don’t intend to support this immediately.
