@hanh just to confirm, this app will NOT fit onto a ledger nano S? Just asking if i have to upgrade or not
It will NOT fit in a Nano S. Orchard is way too complex.
Making the impossible happen @hanh ?
NanoS supports Transparent and Sapling.
I barely managed to make it fit. Less than 100 bytes of RAM left and that’s after manually optimizing the code size by looking at the generated assembly code…
We need testers! If you have a NanoS, or S+ and are proficient with using the command line, you can help by using YWallet 1.4.0 & Ledger.
I tested it tonight on an old NanoS and it worked great!
Here’s a fully shielded Sapling transaction sent from a NanoS:
One cool feature is that transactions aren’t limited in size even on the Nano S.
For example, this one has 6 shielded inputs and 5 shielded outputs.
It is because the tx builder & signer, are streaming.
To my knowledge, that is a first for any wallet/coin.
Just tested this with 1.4.0 and the v1.0.1 zcash-ledger app.
Worked incredibly, really appreciate your work on this!
here’s my versions:
My only feedback is that while signing, the ledger screen flickered a few times? I wasn’t sure if that was intended, but either way it works.
Ledger Nano S+ clear edition if that matters.
Thanks, the app shows different status messages such as processing z-out, etc. The screen may flicker because some of these states don’t last long.
Does anyone have an ear into ledger HQ about this? the activity in the airtable link seems pretty stagnant?
Will this be working on a nano X any time soon?
Will buy S+ and test. Seems cool. Good work
@Dodger please share the status of where this stands.
@pkr - ZCG has been in touch with Ledger. There will be a detailed status update in our 09/18 meeting minutes, which will be published to the forum early next week.
Thank you @aquietinvestor for the quick reply. Looking forward.
Please see the below update, which summarizes where things stand with Ledger. We are in close contact and will provide additional updates as the situation evolves.
It’s critical to discuss with Ledger the ZIP-32 compatibility issue and if they’re willing to add support for ZIP-32 path derivation
Could you clarify why you think it is critical?
Without that there would be effectively two types of seeds, which would require users to pick which one when restoring a wallet (and would lead to endless confusion and topics about funds appearing to be lost when people inevitably pick the wrong choice) or scanning with both paths which would make wallets twice as slow. Both seem pretty bad.
That’s the case with trezor on multiple coins: eth, xmr, ada… Reddit - Dive into anything
It doesn’t seem to be a critical issue to me. One should not share his seed between devices, especially a hardware wallet.