-
Notifications
You must be signed in to change notification settings - Fork 951
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
Murisi/integrate hw masp #3797
base: main
Are you sure you want to change the base?
Murisi/integrate hw masp #3797
Conversation
2e32593
to
8fac040
Compare
3f79328
to
bad72be
Compare
@murisi thanks for PR! Do u mind rebasing this on main? |
cd0decd
to
3fe7ee9
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3797 +/- ##
==========================================
- Coverage 72.83% 72.81% -0.03%
==========================================
Files 338 338
Lines 104220 104306 +86
==========================================
+ Hits 75907 75946 +39
- Misses 28313 28360 +47 ☔ View full report in Codecov by Sentry. |
216861c
to
e448c1a
Compare
e448c1a
to
e08c8b7
Compare
I'm trying to run Something is wrong with the wrapper signature. It fails on Relatedly, do you recall why we disallow |
Thanks for looking into this PR.
I believe that combining
If the hardware wallet produced the wrapper signature for a |
0332a63
to
a375e6e
Compare
Hi @tzemanovic . All the MASP tests now work (when using a variant of the Ledger app with the above PRs merged in) except the |
@@ -63,10 +62,12 @@ pub struct ValidatorData { | |||
/// A Storage area for keys and addresses | |||
#[derive(Serialize, Deserialize, Debug, Default)] | |||
pub struct Store { |
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.
These changes in the wallet store are breaking, but I think we could make them compatible by e.g. trying to deserialize to the current format in case of a failure and migrate to the new format
Everything works well, thanks! But there are some affected unrelated integration tests and it looks like there's maybe a breaking change for IBC/hermes. An observation from UX perspective - a shielded transfer and unshielding transfer require multiple wallet interactions, first to access a viewing key and then 2 more to sign the transfer(s) and again to obtain the signature from the wallet. The last 2 interactions print the same information on the wallet screen, so it appears that it's repeating the same action. I'm not sure if we can do much about that in the wallet, but I think we could at least print something out in the CLI before the request to make it clear what's happening. I'll also add emulator automation for one of the masp tests and we'll need to update the elf file we use in the CI. For local testing I just merged together all the open PRs in ledger-namada. Am I okay to use that? |
One more thing - during a shielded and unshielding transfer when the amount being transferred is lower than the balance of the source, the change that stays in the sender's balance is shown as an obscured receiver payment address so it's not apparent that the destination is the same as the sender. Is there something we can do to improve this? |
…sure removal of MASP Builder data.
…eters cannot be reused. Fixed MASP integration tests depending on access to secret keys.
69704a0
to
7748a05
Compare
Describe your changes
Made the following changes to enable hardware wallet signing of MASP Transactions:
NAMADA_E2E_USE_DEVICE=true
tests
crate into the localnet and hardware genesis files to enable hardware wallet signingstore.toml
in order to ease the manual editing of these files (as done above)Builder
section insign_tx
because it contains private information and because it will be rejected on the basis of not being referred to in the wrapper signature sectionThis PR depends upon the following being merged:
Outstanding issues:
namadaw
's key derivation to match the hardware wallet's to ease checking that the same extended keys are derived for a given mnemonic. However, it might be desirable to revertnamadaw
's derivation to pure ZIP 32 if we desire interoperability with systems implementing this standard strictly. Or perhaps both types of ZIP 32 could be supported with anamadaw
CLI flag to choose which derivation is desired. See a relevant discusssion at https://zecsec.com/audits/zcash-ledger-audit-report-v2.pdf#subsection.3.2 .Checklist before merging
breaking::
labels