Blockchain Commons and Zingo Labs held the first public meeting regarding the Zcash Extensible Wallet Interchange Format (ZeWIF) on January 24, 2025. The goal was to get early feedback on the data being collected in the survey and collated into spreadsheets and diagrams in order to capture Zcash expertise before the specification process began.
Media
|
Meeting Video:
|
Meeting Slides:
|
Key Points
The meeting focused primarily on discussion of the data that has been collected in the wallet data survey and organized in the wallet data spreadsheet. They also covered some basic information on the Envelope format and how to classify data among three classes of importance.
- Accounts: Accounts, which are organizations for logical single pools of funds, are considered important for the user experience. They might be proper ZIP-32 accounts or they might by arbitrary collections of older Sprout or Transparent keys. They might be associated with keys or addresses and they typically have birthdays. They might mistakenly include information that should not actually be part of an account. The ZeWIF spec should represent accounts as seen by exporting wallets, and importing wallets can figure out what to do with them.
- Addresses: A distinction should be made between two sorts of addresses: contact info held in an address book and addresses generated by a user’s own keys.
- Commitment Tree: State information is generally recreateable, but commitment trees were flagged as something that should nonetheless be stored in the wallet interchange format if it exists in the original wallet because of their fiddlyness. The full witness associated with each node should be recorded and then the block height for the entire tree should be as well: either the block height at the time the interchange file was created or the block height of the last transaction in the wallet. If a commitment tree does not exist or is incorrect this is not an issue for the interchange encoder, though a best practice would be to ignore an incorrect tree on import to another wallet.
- Key & Seed Hierarchy: Keys and seeds should be understood to be organized into a hierarchy of increasing power/control that includes: incoming viewing keys (ivks), unified incoming viewing keys (uivks), unified viewing keys (uvks), unified spending keys, HD seeds, and mnemonic phrases. A ZeWIF spec needs to recognize this in some way.
- Transactions: Full transactions should be recorded from wallets even though they could be recreateable from the blockchain. This is a consistency issue, as some wallets store uncrecreateable transactions, such as failed transactions that were not written to the blockchain. Whether transaction information that is incomplete (or nonexistant) in an exporting wallet should be downloaded from the blockchain was left as an open question, but it was not a requirement. Special attention should be given to the parts of transactions that are not recreateable, such as recipient information for shielded transactions and a user’s personal annotations of transactions.
- Transaction Outputs: Transactions and transaction outputs should be clearly separated, as different data can be associated with different outputs for a transaction.
- Wallets: Each wallet should leave its fingerprint (the wallet and the version) in the interchange format, potentially revealing a file that has transversed several wallets over the years. (This means that best practices will have to suggest importing old wallet info.)
We continue to welcome comments on the survey and spreadsheet, focused on what’s needed in the interchange format, what might be missing, and anything that might be misclassified. Please feel free to leave comments on the spreadsheet and please feel free to leave issues on the survey repo.