This is an initial step before moving the Rust backend into a separate Gradle module
- Use primitive values for the Rust backend interface. This will allow the backend to be moved into a new Gradle module in the future, without needing to access the model objects of the SDK
- Add extension functions to the Backend to replace the existing usage of more strongly typed objects. The extension functions can continue to live in the sdk-lib even after refactoring the Rust backend
- Add new decorator that can eventually replace using the Rust backend within the SDK
- Enhanced implementation of SaplingParamTool component. It got sapling files move from legacy folder to the preferred one functionality. It downloads the sapling files atomically now (through the temporary file names). It contains all related constants now. It works with SaplingParamToolProperties, which allows us to easily test the SaplingParamTool functionalities. It also now checks file hashes. Removed unnecessary clear function from the component. Changed valid function.
- Moved related constants from ZcashSdk class to SaplingParamTool class
- Changed Initializer, WalletTransactionEncoder and RustBackend classes to work with File instead of path String
- Minor changes in comments in other classes
- Added getSha1Hash() extension function to the FileExt class
* Related tests
- Two new test fixtures to simplify our tests
- Test for getSha1Hash() extension function
- Minor changes in existing tests
- Created new SaplingParamToolBasicTest, which covers non-integration functionality of SaplingParamTool
- Moved integration tests of the SaplingParamTool to the new SaplingParamToolIntegrationTest and added some new
* Related manual tests
- Created Download sapling files manual test
- Created Move sapling files to no_backup manual test
- Update existing Move database files to no_bakcup manual test
Co-authored-by: Carter Jernigan <git@carterjernigan.com>
We need the transparent account privkey in order to be able to derive
the secret key for any leaf transparent address under the ZIP 316
diversified address tree.
UnifiedViewingKey had a bug that made it incompatible with ZIP 316.
For compatibility with the current `zcash/librustzcash` revision we use
a temporary fake UFVK encoding that stores sufficient information to use
the current APIs, and a superset of the actual ZIP 316 FVK information.
- Replace int with type safe BlockHeight(Long) object
- Fix down casting bug, as BlockHeight is uint32 but Java only supports int32 or int64
- Rename WalletBirthday to Checkpoint and hide from the public API
To quickly get this implemented, some calls in the demo-app have been wrapped in `runBlocking {}`. This is not ideal and will be addressed in followup issues.
Move SDK from the root gradle project to its own Gradle module
Move the demo app to be a peer of the SDK
This will simplify integration with CI on Bitrise.
Carter Jernigan
Jack Grigg
Honza Rychnovsky
Jack Grigg