-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to librustzcash version 0.7 #32
Conversation
Co-authored-by: Kris Nuttycombe <[email protected]> Co-authored-by: Francisco Gindre <[email protected]>
Co-authored-by: str4d <[email protected]>
0e6788d
to
53fd41e
Compare
This modifies our use of `unsafe` to prefer unsafe blocks to fully unsafe function declarations, to make it easier to see what operations are actually unsafe within a function, and then adds safety documentation as appropriate.
This avoids potentially undefined behavior related to previous use of std::mem::forget
Co-authored-by: Daira Hopwood <[email protected]>
Fix undefined behavior in zcashlc_init_accounts_table result.
…xtended_spending_key`
Remove Spending key from `shield_funds`
Closes #26 This implements changes to FFI functions `zcashlc_shield_funds` and `zcashlc_create_to_address` to accept Memos as slices of bytes instead of a null-terminated UTF-8 char array. The receiving functions will attempt to parse the receiving bytes as ZIP-302 compliant and will fail if the rust side fails to parse create `MemoBytes` from the respective `[u8]`. Add support for type safe memos by retrieving them as bytes with `zcashlc_get_received_memo` `zcashlc_get_sent_memo` `zcashlc_byte_array_free` These functions will have to be adopted by the RustWelding layer on ZcashLightClientKit
Co-authored-by: str4d <[email protected]>
[#26] make FFI accept byte slices for memos
Swift lacks fixed-size arrays, so this change makes for a cleaner API on the Swift side, at the expense of slightly less type safety in the C api.
Swift friendly memos
…eiver Add FFI method to access transparent receiver of UA
…odes Add FFI method to extract typecodes of a UA's receivers
This also updates `zcashlc_create_to_address` to take a unified spending key for spending authority instead of a Sapling extended spending key. Also, the unified spending key is now required for shielding. This removes the need to separately derive the transparent spending key, and provides overall a more consistent API experience, such that the caller always works in terms of a single, opaque, binary representation of the spending key. This also removes direct derivation of addresses from the seed, spending key, and viewing key, in favor of using the wallet backend to manage addresses. This is necessary to ensure that diversified addresses produced by this API are properly recorded in the wallet database, so that the transparent receivers associated with newly derived diversified addresses can be correctly monitored for incoming funds. After this change, the direct dependency on hdwallet is no longer needed.
Co-authored-by: Francisco Gindre <[email protected]>
This PR isn't compiling for me. Is |
Yikes. It is certainly not compiling. I didn’t realize this repo doesn’t have any checks, and the build instructions in the README aren’t very helpful. E.g., |
Co-authored-by: Francisco Gindre <[email protected]>
66dd48f
to
7290c49
Compare
Co-authored-by: Daira Hopwood <[email protected]>
f4440b1
to
4170976
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK modulo comments.
Co-authored-by: Daira Hopwood <[email protected]>
b3486e8
to
2096654
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Post-hoc utACK 2096654
No description provided.